Dealing With Contention hard
In a distributed lock (e.g., Redlock), Clinet A acquires the lock but pauses for a long GC. The lock expires. Client B acquires it. Client A wakes up and writes to storage, corrupting B's work. How do 'Fencing Tokens' solve this?
- A They force the GC to stop.
- B They encrypt the lock.
- C They use GPS time.
- D The lock service issues a monotonically increasing token (1, 2, 3...) with each lock. The storage layer rejects any write with a token older than the highest token it has seen (Reject write 33 if 34 has been seen).
Answer: D. The lock service issues a monotonically increasing token (1, 2, 3...) with each lock. The storage layer rejects any write with a token older than the highest token it has seen (Reject write 33 if 34 has been seen).
This is a critical correctness guarantee in distributed systems. Without fencing, 'leases' are unsafe because processes can pause (STW GC) without knowing they lost the lease.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Why is 'Exponential Backoff' preferred over constant intervals for retries?
- What is the primary purpose of a Mutex (Mutual Exclusion) lock?
- Why does adding more threads sometimes *decrease* performance?
- In a Saga, if a Compensating Transaction (Undo) fails repeatedly due to contention, what is the last resort?
- In a database, what happens if Transaction A locks a row and Transaction B tries to modify the same row?
- A database restart causes thousands of application servers to instantly try to reconnect. This crashes the DB again. This is called: