Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptMechanismChapter II · Distribution · Building block 10 of 11

Fencing Token

Delayed writes from a former holder can arrive after a takeover.

By Michael Meierhoff · Meierhoff Systems

  1. GenerationGeneration: Each takeover receives a higher identifier.
  2. ValidationValidation: The protected resource validates every effect.
  3. RejectionRejection: Stale holders lose write access.

Context

Why this is important

Use resource-side enforcement to exclude stale holders.

Use resource-side enforcement to exclude stale holders.

Shop example · Mapping

Fencing Token: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. For invoice B-1042, worker A receives token 41. After a pause, its lease expires and worker B takes over with token 42. B stores the validated invoice status. When A later sends an old write, the database compares 41 with the stored maximum 42 and rejects it. The token must reach the resource that stores the effect; checking only inside the worker would not stop the delayed call.

This is how you read the picture

  1. Generation Generation
  2. Validation Validation
  3. Rejection Rejection
Fencing Token: inspect the decision
ConceptMeaningReview question
GenerationEach takeover receives a higher identifier.Which value is valid after worker B takes over?
ValidationThe protected resource validates every effect.Where must the token be checked?
RejectionStale holders lose write access.What remains unsafe if only the worker checks its token?
Die geschützte Ressource speichert den höchsten akzeptierten Wert und weist ältere Schreibversuche zurück. Der Token schützt dadurch auch dann, wenn ein alter Prozess nach Lease-Ablauf wieder aufwacht. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Use resource-side enforcement to exclude stale holders.
  • Send the token as a precondition with every protected change.

Boundaries

  • A token without validation at the target offers no protection.
  • Monotonicity must survive coordinator restart and storage recovery.

In practice

  1. Create two successive owners for B-1042 and record their monotonically increasing tokens; check where the highest accepted value is stored durably.
  2. After worker B saves, deliberately send worker A’s delayed write with token 41 and expect the database to reject it.
  3. Repeat the test after a database restart and through a second write path so no endpoint bypasses the token comparison or loses the high-water mark.
Read the detailed explanation

A fencing token is a monotonically increasing identifier that binds a resource to a work generation. Each takeover gives the next holder a larger value.

The protected resource stores the highest accepted value and rejects older writes. This protects the resource even when an old process wakes after its lease expires.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. For invoice B-1042, worker A receives token 41. After a pause, its lease expires and worker B takes over with token 42. B stores the validated invoice status. When A later sends an old write, the database compares 41 with the stored maximum 42 and rejects it. The token must reach the resource that stores the effect; checking only inside the worker would not stop the delayed call. lease fencing and lease help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which value is valid after worker B takes over?

    View the solution with justification

    Token 42; a delayed write with token 41 is stale.

  2. ApplyingTransferred to a new situation

    Where must the token be checked?

    View the solution with justification

    At the store or target that commits the protected effect.

  3. EvaluateWeighing an alternative

    What remains unsafe if only the worker checks its token?

    View the solution with justification

    A paused old worker may still issue a delayed write after waking.

Explore further

These building blocks continue the thoughts of this page.

DistributionConsensusContext and comparisonOpening DistributionLeaseConceptual connectionOpening DistributionFailure DetectionConceptual connectionOpening

References

Continue on the learning path

Next in Distributed systems: Lease.

11 Building blocks

Continue withLease