---
title: "Discussion on \"Fencing Tokens in .NET\" | Hashnode"
description: "Discussion on \"Fencing Tokens in .NET\". The Missing Half of Distributed Locks"
url: "https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Fencing Tokens in .NET](https://dotnetdigest.com/fencing-tokens-in-net?utm_source=hashnode&utm_medium=feed)

The Missing Half of Distributed Locks

Aug 4 · 16 min read · dotnetdigest.com  
Read the article

-   [#software-engineering](https://hashnode.com/tag/software-engineering)
-   [#software-development](https://hashnode.com/tag/software-development)
-   [#software-developer](https://hashnode.com/tag/software-developer)
-   [#web-developer](https://hashnode.com/tag/web-developer)
-   [#web-development](https://hashnode.com/tag/web-development)
-   [#microsoft](https://hashnode.com/tag/microsoft)
-   [#dotnet](https://hashnode.com/tag/dotnet)
-   [#csharp](https://hashnode.com/tag/csharp)
-   [#software-architecture](https://hashnode.com/tag/software-architecture)
-   [#solutionarchitect](https://hashnode.com/tag/solutionarchitect)

## Written by

[Patrick Kearns](https://hashnode.com/@fullstackcity)

@fullstackcity · Dublin

  
[View profile](https://hashnode.com/@fullstackcity)

Senior .Net Engineer

Senior Software Engineer specialising in cloud architecture, distributed systems, and modern .NET development, with over two decades of experience designing and delivering enterprise platforms in financial, insurance, and high-scale commercial environments. My focus is on building systems that are reliable, scalable, and maintainable over the long term. I’ve led modernisation initiatives moving legacy platforms to cloud-native Azure architectures, designed high-throughput streaming solutions to eliminate performance bottlenecks, and implemented secure microservices environments using container-based deployment models and event-driven integration patterns. From an architecture perspective, I have strong practical experience applying approaches such as Vertical Slice Architecture, Domain-Driven Design, Clean Architecture, and Hexagonal Architecture. I’m particularly interested in modular system design that balances delivery speed with long-term sustainability, and I enjoy solving complex problems involving distributed workflows, performance optimisation, and system reliability. I enjoy mentoring engineers, contributing to architectural decisions, and helping teams simplify complex systems into clear, maintainable designs. I’m always open to connecting with other engineers, architects, and technology leaders working on modern cloud and distributed system challenges.

## Responses 5

Markdown supported · ⌘↵ to post

[Evelyn Wyatt](https://hashnode.com/@Evelynwyatt)

[Aug 6](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7458a7d81501016f5fb3cf)

One point worth emphasizing is that leader election solves who should act, while fencing tokens enforce who is allowed to commit changes. That separation makes distributed systems much more resilient because correctness is enforced at the write boundary rather than relying on every node to behave perfectly.

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Aug 6](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7458a7d81501016f5fb3cf#reply-6a74f4e7460ce63f8aedeac0)

Exactly, a good point. And you can guarantee that anyone that does expect their system to behave as it should all of the time is in for a shock!

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Aug 5](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58)

The write-boundary requirement is the part many lock implementations miss. If the final side effect is an object store, message broker, or third-party API that cannot atomically compare the generation, the fencing token is only evidence, not enforcement. One practical pattern is to write through a small authoritative service or database row that records the highest accepted token and an idempotency key before emitting the external effect. I would test delayed requests explicitly by holding token N, committing N+1, then releasing N and proving every downstream path rejects or deduplicates it.

[Aug 6](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58#reply-6a74f47729c331c8cf10da5d)

A great way to test it!

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Aug 21](https://hashnode.com/posts/fencing-tokens-in-net/6a723685183addc17be0b86b/comment/6a7372845fe4af08364bdf58#reply-6a87e22f915273a59339613a)

Thanks. I like turning the stale-holder case into a deterministic integration test because it catches token-propagation gaps, not just lock acquisition bugs. The key assertion is that token N causes no external side effect after N+1 has been accepted, including retries and delayed messages.