Section 1: The Question Under Every Other Question - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes of the 401 interview's purest infrastructure prompt — a distributed key-value store. We name the two failure archetypes this question is built to expose, decompose the prompt the way infrastructure demands (tenants instead of users, guarantees instead of features), and walk the clarifying exchange in which each answer eliminates an entire category of design work. By the end, the problem is scoped, the assumptions are written down, and one question — the most important one — has been deliberately left hanging.

The interviewer doesn't slide over a product. They slide over a foundation:

"Design a distributed key-value store — a Dynamo-class system: get, put, delete by key, running across a fleet of commodity machines. Your platform teams will build on it, so you own its latency, durability, and failure behavior."

If you've studied for this level, you feel the reflex immediately: I know this one. Consistent hashing. Vector clocks. Gossip. Merkle trees. The Dynamo paper's table of contents rises in your throat, and the strongest move you can make in the first sixty seconds is to swallow it. Because this prompt is engineered to catch two specific candidates, and the interviewer has seen hundreds of both.

The first is the Paper Reciter — fluent in Dynamo's vocabulary, able to name every mechanism, unable to say why any of them exists or when you'd leave one out. Ask the Reciter "why vector clocks?" and you get a definition, not a reason. The second is the Single-Node Thinker — who designs a genuinely excellent storage engine, then gestures at "replication" as if it were a deployment checkbox rather than the place where half the hard problems live. One candidate has read about the system; the other has only ever built a smaller one. Neither has derived it.

Key Insight: The passing move for this entire module is a single discipline — derive every mechanism from the failure it prevents. Not "Dynamo uses hinted handoff," but "a node died mid-write and the write still had to succeed, so here's what must exist." A candidate who can replay that derivation can defend any design decision under pushback; a candidate who memorized the answer can only repeat it louder.

Decomposing an Infrastructure Prompt

The what/who/why/how decomposition you'd run on any product prompt still applies — but for infrastructure, every dimension reads differently, and noticing that is the first signal you send:

• What it does: Three verbs — get, put, delete — by key, across a fleet. The smallness is deceptive, exactly like the Color Picker in the Deceptively Simple Systems module, but inverted: there the simplicity hid a test of restraint; here it hides the fact that every one of those verbs must keep its promise while machines are dying underneath it.
• Who uses it: Not end users — tenants. The checkout team, the flags team, the session team: other engineers, each shipping their own product on top of yours. They will read your documentation once and your failure behavior forever. The "user interface" is a client SDK and a contract measured in p99s and nines.
• Why it exists: Because the real alternative is a dozen teams each hand-rolling their own storage — a dozen replication schemes, a dozen 2 a.m. pages, a dozen subtly different answers to "what happens when a node dies." One hardened store, owned by one team, amortizes the hardest problems in distributed systems across the whole company. That's the business case, and stating it shows you know what a platform is for.
• How it's used: Programmatically, at high frequency, deep in other systems' hot paths. Nobody tolerates "a hundred milliseconds is fine" here; your latency is a line item inside every tenant's latency budget.

That last box is the one to say out loud: in an app design, an internal mechanism is invisible if the feature works. In infrastructure, every mechanism leaks into a semantic — what happens on a conflicting write, on a dead replica, on a network partition — and your tenants will build logic on top of whatever answer you give. There is no "implementation detail" at this altitude.

Quick check before moving on: