Fencing Tokens

Giriş

Açıklaması şöyle

Distributed systems concept: Fencing Tokens

You designed a fancy distributed locking algorithm just to find that an old primary is able to overwrite data!

The problem:

- Node A holds the lock, and is doing some work.

- Node A gets disconnected/unresponsive/crashes, and resume execution after its lease expires ("true" time)

- Node B, in the meantime, acquired the lock and wrote some data.

- Node A resume executions, thinking their lock is still valid

- Node A overwrites the data written by Node B, even tho it doesn't have the lock anymore.

That's were fencing token comes in: when a node acquires the lock, it gets a token with a monotonically increasing number. When the node tries to write data, it must include the token. If the token is outdated (i.e., lower than the current token), the write is rejected, preventing stale nodes from overwriting newer data.

Fencing tokens are used in a variety of systems, like etcd

The big takeaway is that you can't rely on just the client to know whether they are in their right. The target resource must have a gating mechanism to verify that the request makes sense.