Fencing Token
A monotonically increasing number issued with leadership or a lock, checked by the resource, so writes from a deposed holder are rejected.
The control that makes leadership safe rather than merely likely. Every time leadership or a lock is granted, the coordination service issues a number one higher than the last. The holder includes that token with every write, and the storage layer refuses any write carrying a token lower than the highest it has already seen.
This converts a timing problem into an ordering problem. It no longer matters whether an old leader believes it is still leader, whether its clock is wrong, or whether it was paused for thirty seconds — its token is stale and its writes are rejected deterministically.
The requirement that makes it awkward in practice is that the resource must participate. A storage system that does not check tokens gives you no protection, however careful the coordination layer is. This is why distributed locking against a plain object store or a legacy database is much weaker than it appears, and why the safest designs push the check into the system that owns the data.
Where the resource cannot check tokens, the honest position is that you have reduced the probability of a split-brain write, not eliminated it.