Section 11: The Gauntlet - Interviewer Deep-Dive Challenges

Executive Summary: The interviewer tries six ways to break the cell: swap it for Redis, multiply the clients by ten, demand per-row locks at 50,000 acquires/s, rewrite a file cached by 50,000 sessions every second, strand the master on a minority, and claim the design rests on clocks. Every strong answer is mechanism, number, trade-off, reusing what Sections 7 to 10 built. Two of the six are won by saying no.

The interviewer leans back. "Okay, I believe the failover. Now let me try to break it."

You: "For each one I'll give you the number first, then the mechanism, then what it costs."

Challenge 1: Why Not Just Use Redis?

Interviewer: "This is a lot of machinery. Every team I know does SET lock NX PX 30000 on Redis. If you're nervous, use Redlock."

The weak answer is "Redis isn't consistent." That's a slogan, not an argument.

You: "Start with single-instance Redis and a replica. Replication is asynchronous, so a failover can lose an acknowledged lock:"

You: "Redlock fixes that failure: the client acquires the key on a majority of N independent Redis masters, typically 3 of 5, and trusts the lock only for the TTL minus the time acquisition took, minus a drift allowance. Martin Kleppmann's 2016 critique made two points. Redlock issues no fencing token, so the resource can't stop a client that pauses past its validity time, and its safety rests on timing assumptions: bounded delay, bounded pauses, clocks that don't jump. Antirez replied that those assumptions hold on well-run systems, that every auto-expiring lock has the pause problem, and that a resource able to check a token could check Redlock's random value with compare-and-set instead. Fair: ours has the pause too. The difference is that our token is ordered, so a resource can reject an old holder without ever having talked to it. When master-b wakes from its 40 s GC pause and sends a command stamped with generation 41, the tablet server has seen 42 and rejects it. The pause ends in a rejected command, not two leaders acting."

You: "So Redis is fine for an efficiency lock, like keeping a cron from running twice, where a double run wastes some compute. A correctness lock needs a monotonic token the resource checks (D10), in lock state that survives failover (D3). That's why per-lock TTLs lost to sessions in D8."

Quick check before moving on: