Fencing Token Rejects the Zombie — Token 33 Meets Token 34 Diagram

The Token Rule

Every time the lock service grants a lease it also hands out a fencing token, a number that only ever increases
Every write to storage must carry the sender's current token
Storage remembers the highest token it has accepted and rejects any write with a lower one

Why the Zombie Loses

Client 1 paused, its lease expired, and client 2 took over with the higher token 34
Client 1's late write carries 33, so storage refuses it with 409 even though the request is otherwise valid
Without the token check the two writes would interleave and corrupt the object — this bug really existed in HBase

Same Idea, Other Names

Chubby calls it a sequencer, Kafka calls it an epoch, Paxos uses ballot numbers and Raft uses term numbers
Object storage exposes conditional writes (S3), conditional headers (Azure Blob), and request preconditions (GCS)
Fencing is permanent — unlike optimistic concurrency control, a rejected zombie cannot simply retry