Code10x
Distributed systemssenior8+ years

A team is deciding whether to use Redis's Redlock algorithm (acquiring a lock across a majority of independent Redis nodes) for a correctness-critical operation — one where two holders acting at once would corrupt data. What does Redlock's quorum actually buy over a single Redis instance, and where does Martin Kleppmann's critique of it actually land?

Redlock's quorum genuinely solves a real problem a single Redis instance has: if a single instance fails over to a replica that hadn't yet received the lock key, a second client can acquire the same lock — Redlock's majority requirement across independent nodes makes that specific failure need a majority of nodes to be simultaneously wrong, which is a real, materially stronger guarantee than trusting one instance's replication timing. Kleppmann's critique isn't that Redlock's quorum arithmetic is wrong — it's that the algorithm's own "the elapsed time must be meaningfully less than the lock's validity time" check silently assumes the client's clock and process never do anything strange in between (no long GC pause, no VM freeze, no clock jump), and that Redlock as originally specified hands out no fencing token, so even a correctly-acquired Redlock can't stop a paused holder from writing stale data later. This is a real, still-debated disagreement between two people who agree on the facts and differ on how much synchrony a lock is allowed to assume — not a case where one side has been shown wrong.

The lesson behind it →
PreviousUnder write latency pressure, a team proposes switching a Redis-backed cache from write-through to write-behind: acknowledge the write immediately, buffer it, and flush to the database on a schedule. What exactly is being traded away, and is it a bug to fix or a tradeoff to make deliberately?Next A cache entry costing 300 ms to rebuild is protected from a stampede by probabilistic early expiration (XFetch) instead of a Redis rebuild lock. Walk through the actual formula being evaluated on every read, and explain precisely why a read close to the entry's expiry is far more likely to trigger an early rebuild than one early in the entry's life — without the formula needing to know explicitly how much time is left.
More on Distributed systems
Three service instances coordinate through a Redis lock (`SET lock:invoice-1041 <owner> NX PX 1000`) before sending an invoice, so only one should send it. Worker A acquires the lock, then a GC pause holds it inside its critical section for 1.5 seconds — longer than the lock's 1-second expiry. Walk through what actually happens, and what a plain `DEL` on release makes worse.