What system design is
System design is not trivia about famous architectures — it is the discipline of reasoning from requirements to bottlenecks to tradeoffs under scale and failure. There is rarely one right answer, only defensible ones. This is what coding stops teaching you.
Two engineers are asked to “build a URL shortener.” The first opens an editor and writes a route that hashes the long URL, stores the pair in a table, and redirects on lookup. It works on their laptop in twenty minutes. The second asks: how many writes per second, how many reads, how short must the code be, what happens when two requests hash to the same slot, what happens when the database falls over at 3 a.m.? The first engineer wrote code. The second was doing system design — and only their version survives contact with a million users. The gap between those two responses is the entire subject of this track. By the end of this lesson you will know exactly why that gap exists and how to start closing it.
It is not trivia
When you sit down to a system design interview — or write a real design doc — the most expensive mistake is treating it as a recall exercise. A widespread misconception is that system design means memorizing how Twitter or Netflix is built, then reciting the diagram. That is the opposite of the skill. Real architectures are answers to specific constraints — a particular read/write ratio, a particular latency budget, a particular team and budget — and copying the answer without the question gives you a cargo-cult design that fits nobody. System design is not a body of facts to recall; it is a way of reasoning you can apply to a problem you have never seen.
The reasoning runs in one direction, and the order matters:
- Requirements — what must the system actually do, and how well? (functional and non-functional)
- Bottlenecks — given those requirements at the stated scale, which resource gives out first?
- Tradeoffs — what do you spend (consistency, simplicity, cost, latency) to relieve that bottleneck?
Skip step 1 and you optimize the wrong thing. Skip step 2 and you scale the part that was never going to break. Step 3 is where seniority shows: there is almost never a free win, only a chosen cost.
Coding versus designing
Coding asks “does this function produce the correct output?” — a question with a binary answer you can unit-test. Designing asks “does this system hold up under load it has never seen, failures you cannot predict, and growth you cannot stop?” — a question with no test that returns green. A function is correct or it isn’t. A design is only ever defensible or not: it makes its assumptions explicit, names the load it targets, and states what it sacrifices and why.
This is why “it works on my laptop” is the beginning of the conversation, not the end. When you catch yourself thinking “the tests pass, we’re good,” ask: good at what scale, under what failure, for which user? The laptop has one user, no concurrency, no network partition, no disk that fills at midnight. Designing is the practice of reasoning about everything the laptop hid from you.
▸Why this works
Why is there “rarely one right answer”? Because every meaningful design choice trades one desirable property for another, and which trade is correct depends entirely on requirements you were handed, not on the technology. Strong consistency or low latency? More denormalization (fast reads, painful writes) or strict normalization (clean writes, slower reads)? A monolith (simple, one deploy, one failure domain) or services (independent scaling, distributed-systems tax)? None of these has a universally right side. The senior move is not to know “the answer” — it is to surface the tradeoff out loud, tie it to the stated requirement, and pick the side that requirement demands. A junior says “use Postgres.” A senior says “Postgres, because we need transactions and our 5k writes/sec fits one primary — if writes 10× we revisit sharding.”
A concrete mini-example
Take the shortener. The requirements interview reveals: 100 reads for every 1 write, redirects must feel instant (p99 under 50 ms), codes should be short, and a redirect failing is far worse than a creation failing. Now the design writes itself from the requirements, not from a tutorial:
- 100:1 read-heavy → put a cache in front of reads; the working set of hot links lives in memory.
- “instant redirect” → the read path must avoid a slow lookup; precompute and cache, never compute on the hot path.
- “short codes” → don’t hash (collisions, length); hand out a counter and base-62 encode it.
- “redirect failure is worst” → make the read path the most replicated, most cached, least fragile component, and let the write path be the one that degrades first.
The point is not that this is the shortener design. It is that a different requirements set — say, write-heavy analytics ingestion, or codes that must never be guessable — flips half of these decisions. The flow stayed the same; the answer changed because the requirements changed. That is system design.
What this track covers
This is the foundations track: the load-bearing concepts you reuse in every design, regardless of the specific product. The early units build the vocabulary and the physics — scalability (latency, throughput, scaling axes, the numbers every engineer should know), then data distribution, caching, consistency, communication, reliability, and the rest. A later unit (unit 09) takes the loose reasoning above and hardens it into the explicit, repeatable design frame — the checklist you walk through under pressure. A separate cases track then spends that vocabulary on full end-to-end designs (a shortener, a feed, a rate limiter, a chat system), where you watch the foundations combine into real architectures.
An interviewer asks you to design a photo-sharing service. Which opening move is the system-design move, rather than the coding move?
Why does system design have 'rarely one right answer, only defensible ones'?
Coding asks whether a function returns the correct output — a binary, testable question. Designing asks whether a system holds up under load and failure it has never seen, so a design is never simply 'correct'; it can only be _______ — it states its assumptions, names the scale it targets, and justifies what it sacrifices.
- 01What is the three-step reasoning flow of system design, and why does the order matter?
- 02How is designing different from coding?
- 03Why is there rarely one right answer in system design?
System design is not trivia — not memorizing how Twitter is built, but a way of reasoning you apply to problems you’ve never seen. It runs in a fixed order: requirements → bottlenecks → tradeoffs, under the pressures of scale and failure. Coding asks the binary, testable question “is this function correct?”; designing asks “does this system hold up?” — for which no harness returns green, so a design is only ever defensible: explicit about its assumptions, its target load, and the cost it accepts. Because every real choice trades one good property for another, there is rarely one right answer — a read-heavy and a write-heavy version of the same product want different designs. This foundations track builds the reusable concepts (scalability, data distribution, caching, consistency, communication, reliability); unit 09 hardens the loose reasoning here into an explicit, repeatable frame; and a separate cases track spends that vocabulary on full end-to-end designs. Now when you see an engineer jump straight to “we need Kafka” — or when you feel that pull yourself — you will recognise it as the coding move: choosing technology before requirements, skipping the reasoning that makes the choice defensible.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.