</> MAANG.io

Expert

Design landmark systems in depth, from Dynamo, GFS, Bigtable and Kafka to payments and ads pipelines.

0 of 232 solved 0%

Section 12: Doors Left Unlocked - Follow-up Feature Evolution

Executive Summary: The last ten minutes test whether the design grows by addition. Six evolutions arrive, each at a ledger trigger: proxies past 150,000 sessions per cell; namespace partitioning only past ~5,000 writes/s or ~10 GB; a global cell (5 regions, ~70 ms commits, ~10 writes/s) whose small hot files are mirrored into every DC cell; a name service that replaces DNS TTLs with invalidated caches; ordered-waiter recipes built from ephemeral sequential nodes; and per-directory quotas with self-service onboarding. None of them changes the replicated log, the session lease, or the sequencer. That is the grade.

The interviewer turns back to the first page. "You put proxies, partitioning and the global cell on a list called 'later'. It's later. Which one hurts?"

You: "None, because the core contract is small: one ordered log per cell, sessions with 12 s leases, caches invalidated before commit, and a lock generation on every lock. Everything on that list is either a client of that contract or another copy of it."

Proxies: Building What Section 11 Argued For

Section 11's Interviewer Deep-Dive Challenges already settled why. Past 150,000 sessions per cell, the failover storm reaches 30,000 RPC/s, 60% of the ceiling, over the 40% plan. Longer leases are rejected because 60 s still means 16,667 KeepAlives/s at a million sessions, and dead clients take a minute to detect. So here is how we build them.

A proxy is a lock-service client that also speaks the lock-service protocol to its own clients. It fronts ~5,000 clients, answers their KeepAlives locally, serves reads from its own consistent cache, and forwards writes and Acquires to the master. The master sees one KeepAlive stream per proxy, but each client still owns a replicated sub-session, so its locks and ephemeral nodes belong to the client, not the proxy. The proxy's KeepAlive vouches for all its clients at once. When a proxy dies, the master doesn't expire its clients' sub-sessions with it. It gives them the same fresh 60 s window a new master gives (Section 10), and each client re-attaches through another proxy with one resume RPC. Session create and expire still go through the log, so proxies cut KeepAlives and reads, not writes. At 1,000,000 clients that is 200 proxies, ~17 KeepAlives/s. When the master invalidates a node, it invalidates the proxy, and the proxy invalidates its own cachers before acknowledging, so invalidate-before-commit (D9) still holds end to end.

Interviewer: "What did you just add?"

You: "A hop on every write, and a new blast radius. A dead proxy is a small failover for its 5,000 clients: they go into jeopardy while the master holds their sub-sessions for 60 s, and each re-attaches through another proxy within its 45 s grace, the same resume Section 10 built. At 100,000 sessions today, 20 proxies would be optional, so we don't deploy them yet."

What stays untouched: consensus, the data model, the client API, sequencers.

Quick check before moving on:


Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.