A fencing token guards against a stale leader
A distributed lock looks simple, but when a client stalls and wakes late its claim to that lock becomes stale; the fencing token turns that stale claim into a verifiable number. A lock alone is not enough A distributed lock protects a resource from two writers, but it does nothing about a writer that already lost the lock. Network latency can freeze one node mid-write, the lease expires, another leader takes over, and the old leader resumes from the stale frame it still remembers as its permission. This is the classic condition a lock cannot see: the writer no longer holds the token but still believes it does. The result is corruption that looks like two legitimate owners wrote different data, because from the resource’s view both held valid credentials at different instants. Depending only on a hopeful lease expiry leaves a window where the corruption is baked in before anyone notices. ...