The Twelve Worked Designs

Every design in Track C, worked end to end: nine sections, then attacked by a hostile staff-level interviewer, then revised. Six critiques per design, each naming a real defect in the first draft.

Attempt each one yourself before reading it. Reading a worked answer teaches you what good looks like; writing one under a clock teaches you to produce it. The value is in the second.

Table of Contents

How to Use These

For each design, in this order:

  1. Read only the prompt. Stop there.
  2. Write your own, 45 minutes, against the template. Timer on, diagram in Excalidraw.
  3. Score yourself against ../../../diagnostics/RUBRIC.md before reading further — you are measuring your judgement, not your ability to recognize good judgement when shown it.
  4. Read sections 1–10 and note every gap.
  5. Read the hostile critique. Try to answer each one before reading the revision.
  6. Read the revision. The gap between your answer and it is the actual finding.
  7. Everything you missed goes into ../../../review/ at the 1-day interval.

The critique is the point. Every one of these designs is wrong in section 5 and right in the revision, and the six defects found per design are the kind you will find in your own work if you learn to attack it. That is the transferable skill — not the designs themselves.

The Twelve

#DesignThe two hard partsWhy it is in the set
d01Fault-tolerant job schedulerexactly-once dispatch under scheduler failure · worker liveness, leases, split brainThe reported screen question. Do this first
d02Distributed versioned KV storeglobal version ordering · consistent snapshots across shardsThe distributed counterpart to the reported coding question. Connects the two rounds
d03Distributed rate limiteratomic check-and-decrement · fail-open vs fail-closedSmall surface, deep tradeoffs. Good early confidence
d04Webhook delivery systemper-destination isolation · at-least-once without floodingThe reported take-home, as a design round
d05Load shedding gatewaywhat signal to shed on · what to dropThe reliability primitive everything else leans on
d06Feature storepoint-in-time correctness · training/serving skewYour background — expect the hardest push
d07Log analytics pipelineingest backpressure · index cost vs query costIngest, index and query want opposite things
d08Multi-region metadata storewhere the write goes · read-your-writes across regionsWhere consistency stops being free
d09Search / retrieval servingthe fan-out tail · index freshness vs latencyYour strongest area; portfolio-adjacent
d10Event streaming platformordering vs parallelism · consumer group rebalancingThe thing the others depend on
d11Distributed lock servicewhy a correct lock is not enough · sessions and clocksFencing, in full. The highest-value single concept
d12Multi-tenant control planeisolation and blast radius · reconciliationTies the set together

The Two Hard Parts, Per Design

The single most-weighted rubric line is whether you identified the right hard parts. Here they all are — and the drill is to read a prompt and name them in 60 seconds, before any diagram.

The four questions that find them (warmup §0.3):

  1. Where must ≥2 machines agree on state?
  2. Where can data be lost?
  3. What is the highest-rate or highest-cardinality thing?
  4. Where does one tenant's behaviour affect another's?

Notice how often the answer is the same shape: something must be agreed on, and something must not be lost.

Cross-Cutting Patterns

The same ideas recur, which is the point — twelve designs, roughly a dozen primitives.

PatternWhere it appears
Fencing tokensd01 (job dispatch) · d02 (shard rebalance) · d11 (the whole design) · d12 (cell migration)
The outbox / no dual writed01 (dispatch) · d04 (event → deliveries) · d10 (as the log itself)
Per-X isolation capsd04 (per destination) · d05 (per class) · d09 (per shard) · d12 (per tenant)
Circuit breakersd04 · d05 · d09
Reserved floors, not pure priorityd05 (shed classes) · d12 (fair queueing) · d04 (backlog drain)
Bloom filters / probabilistic pruningd07 (segment pruning) · d09 (index) · and in Track A ch.9
Predecessor queriesd02 (as-of reads) · d06 (point-in-time join) · Track A ch.1
Immutable segments + merged07 · d09 · d10
Static stability / last-known-goodd08 (config) · d12 (data planes)
The recovery rampd01 (catch-up) · d04 (circuit close) · d07 (backlog) · d10 (consumer lag)
Cells / shuffle shardingd12 · noted in d05
Level-triggered, not edge-triggeredd12 (reconciliation) · d08 (config push)
Session guarantees over linearizabilityd02 · d08

If you can name where a primitive recurs, you understand it. If you can only name where you first read about it, you do not yet.

What the Critiques Found

Seventy-two critiques across twelve designs. The defects cluster, and the clusters are the lesson — these are the things your first draft will get wrong too.

Defect classCountExample
A stated SLO the design violates8d01: enqueue gap makes dispatch 60 s late against a 1 s SLO
An uncosted hot path11d05: circuit state read on every request = 1M reads/s
A guarantee overclaimed9d04: fencing cited for a resource we do not control
A failure mode with no detection7d09: degraded results silently corrupting A/B tests
Arithmetic never done10d10: 40 GB segment × 60 replicas = 2.4 TB from one node
A policy that starves someone6d04: backlog never drains under sustained load
A recovery path that is untested5d12: the emergency rollout nobody has run in 8 months
A shared dependency claimed absent4d12: registry, secrets, DNS, metrics
Wrong granularity8d11: a global fence for a per-resource comparison
An assumption that only holds when healthy4d09: hedging calibrated on the healthy distribution

The most common single failure is arithmetic never done. Ten of twelve first drafts asserted something that a two-line calculation disproves. That is the cheapest possible improvement to your own designs: before defending a component, size it.

The Order to Work Them

Mandatory first, in this order:

  1. d01 — the reported screen question. Leases, fencing, at-least-once.
  2. d11 — fencing in full. d01 uses it; this explains it.
  3. d02 — the bridge to the coding round.

Then by leverage:

  1. d05 — the primitive the rest lean on
  2. d04 — feeds ../../../projects/
  3. d09 — your strongest area; make it your best answer
  4. d06 — your background, hardest push
  5. d10 — ordering vs parallelism
  6. d03 — quick, and sharpens the fail-open decision
  7. d08 — where consistency stops being free
  8. d07 — the economics of indexing
  9. d12 — the synthesis

One per week, 45 minutes to write plus 30 to critique. Twelve weeks, which fits inside the 26-week program with room to redo the two mandatory ones cold.

References