Fencing Token

Definition

A fencing token is a monotonically increasing number issued with each new lease or lock. Every protected write carries the number, and the destination rejects numbers older than the greatest one it has accepted. This prevents a delayed former holder from changing the resource after ownership has moved on.

In plain terms

Expiry does not stop an old worker from waking up. Give each successive holder a larger ticket: 41, then 42, then 43. Once the storage system has seen ticket 43, it refuses a late write carrying 42 even if that worker still believes it owns the job.

The check has to happen at the resource being protected. If only the coordinator checks the token, a stale worker may bypass it and write directly to the database or file service.

Example

Worker A receives lease token 17, pauses, and misses renewal. Worker B receives token 18 and writes a result. A then resumes and tries to write with 17.

Common misunderstandings

• “The lease alone stops stale writes.” The old process may continue after expiry; the destination needs a way to reject it.
• “A random unique identifier is enough.” Uniqueness does not say which holder is newer; fencing needs an ordered value.
• “Every external service supports fencing.” Many do not. Use their idempotency mechanism or avoid automatic retry when the side effect cannot be protected.