Redlock, lease timing and the limits of fencing
Read Redis’s conditional lease model alongside the distinct arguments of Martin Kleppmann and Salvatore Sanfilippo; a lock grant is not a storage-side guarantee.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Redlock coordinates a time-limited lease under timing assumptions; fencing is a separate resource-side check on request order.
Conceptual illustration, not a tested failure timeline.
Start with the protected resource
A lease grants time-limited coordination; it does not itself stop a client from sending a request after expiration. Redis documentation describes a failover race when a primary grants a lock and crashes before asynchronous replication transfers it. Its random owner value helps prevent a client from releasing somebody else’s lock, rather than ordering every write to the protected resource. Redis lock model
An illustrative design review can begin with the operation, not the lock library. Write down who grants permission, who performs work and who accepts its result. Those can be different components. If two workers calculate the same disposable result, the consequences differ from two workers changing an authoritative record. This comparison identifies the question to investigate; it does not select a proven implementation or establish that locking is the only possible coordination mechanism.
Read majority acquisition as a conditional window
Current Redis documentation describes parallel acquisition attempts across independent masters. Five nodes is its example, not a universal deployment requirement. The client checks majority acquisition and elapsed time; usable time is reduced by acquisition time and a drift allowance. Work must finish within the applicable validity window under the stated relative-clock assumptions. Acquisition and validity
For a hypothetical timeline, keep three intervals separate: seeking the lease, holding the remaining lease and sending work to the resource. No numeric duration is needed to see why a slow acquisition leaves less time for work. Also distinguish a successful reply from knowledge of the eventual side effect. A diagram ending at the grant hides the later operation that actually matters. This is a reading exercise, not a measurement of retries or network latency.
Expert perspectives disagree about the model
In his 8 February 2016 blog analysis, Martin Kleppmann questions Redlock for correctness-dependent uses, emphasizing pauses and delayed requests that outlive leases. His efficiency discussion recommends simpler locking, rather than endorsing Redlock for that purpose. Salvatore Sanfilippo’s response defends a bounded relative-time model and the elapsed-time acquisition check; it distinguishes acquisition delay from later work overrunning a lease. These are authored arguments, not a peer-reviewed proof or a settled agreement. Kleppmann critique Sanfilippo response
Read each conclusion with its assumptions attached. Asking whether machines share an identical clock is different from asking whether local clocks progress within an acceptable relative bound. Similarly, accounting for time spent obtaining a grant is different from preventing a paused holder’s later request. An argument answering one question should not be treated as an answer to the other. Historical intentions about clock APIs are not evidence of a present implementation.
Fencing depends on the resource seeing order
Kleppmann describes increasing fencing tokens checked by the receiving resource: a request carrying an older token is rejected relative to a higher token already observed there. This differs from the random owner token used for conditional release. Fencing requires participation by the protected resource, and does not instantly revoke every expired holder or automatically make transactions serializable. Resource-side fencing
In an illustrative sequence, an old request arriving before the resource has seen a newer token cannot be rejected merely because that newer grant exists elsewhere. Draw the grant order and arrival order separately. Then identify the exact component comparing the token and performing the effect. Reliable enforcement of that comparison is an implementation condition to investigate, not an unconditional promise from these articles. An external effect that never checks the token remains a separate boundary.
Review the assumptions before using a conclusion
The current Redis page acknowledges wall-clock TTL concerns and advises considering fencing. That documentation does not retroactively make the two authors’ models identical. Keep source dates and positions distinct when using the debate in a design review. Redis consistency disclaimer
A useful review sheet records the tolerated failure, timing assumption, lease-overrun behavior, resource-side enforcement and evidence actually collected. Mark unknowns instead of replacing them with “safe” or “unsafe” for every environment. If a test observes one pause scenario, it has not explored all scheduling or failure combinations; if no test was run, do not label the timeline a result. This article supplies conceptual distinctions and hypothetical reading exercises, not a Redis deployment test, a formal proof, or an assurance about financial correctness.