Estimate, decide, defend
Each brief is an exercise with an answer underneath. Read the requirements, design it yourself — including the arithmetic — and then compare. Every number states its assumptions and every decision states its cost, because a number without its inputs teaches you to recite, and a fork with only an upside is not a decision.
13 of 13
- Scale & cachingFoundationA URL shortener that is mostly a read problem
The interview classic, and the reason it is asked: almost everyone designs the write path, and almost all of the traffic is on the read path.
- ReliabilityIntermediateA rate limiter that is fair when it is distributed
Every algorithm here is a few lines on one machine. The design question is what happens when there are twenty machines and they disagree.
- Scale & cachingIntermediateA feed, and the fan-out decision underneath it
Read-time or write-time is the only question here, and the honest answer is that a real system does both and switches between them per account.
- Data & consistencyAdvancedTaking a payment exactly once, over a network that will not let you
The client retried because it saw a timeout. The first request had already succeeded. Everything in this design exists because of that sentence.
- Queues & eventsAdvancedA job scheduler that runs a job once, on time, on some machine
Cron on one box is five minutes of work. Cron on twenty boxes, where any of them can die mid-job, is this.
- Search & rankingSeniorAutocomplete, where the latency budget is a keystroke
Every design choice here is downstream of one constraint: the answer must arrive before the user types the next character.
- Data & consistencyIntermediateTicket booking, where two people want the same seat
The whole design is one guarantee — a seat is sold at most once — held under the worst traffic the system will ever see, in the first minute of an on-sale.
- Data & consistencyAdvancedCheckout and inventory, without overselling the last one
Checkout touches three things that fail independently — stock, payment and the order — and the design is mostly about what happens when one of them succeeds and the next does not.
- Queues & eventsIntermediateNotifications, where the password reset must not wait behind the newsletter
Sending a message is easy. Sending the right one, once, on the right channel, while a marketing campaign of ten million is in the same pipes, is the design.
- Queues & eventsSeniorChat, where order and 'delivered' have to mean something
Millions of long-lived connections, messages that must appear in the same order for everyone in a conversation, and a phone that goes offline in a tunnel mid-send.
- Scale & cachingSeniorRide matching, where the data is a moving map
Most of the writes in this system are positions that are out of date four seconds later. Treating them like database records is the first mistake and the most expensive one.
- Scale & cachingIntermediateFile upload and storage, where the bytes never touch your servers
Large files through an application server is the design most systems start with and the first one they replace. The better design sends bytes straight to storage and keeps only the record.
- ReliabilityAdvancedA logging and metrics platform that cannot take production down with it
The platform you use to debug an incident receives its heaviest load during that incident. Designing it means deciding, in advance, what it drops.