Discussion on "Fencing Tokens in .NET"

Patrick Kearns · 2026-08-04T18:59:17.611Z

Distributed-lock examples usually finish once one application instance has acquired a lease and every other instance has been refused. The code enters a try block, performs the work and releases the l

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.

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!

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.

A great way to test it!

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.

Search Hashnode

Fencing Tokens in .NET

Responses(5)