What System Design Actually Tests

Whether it's an interview or a real project kickoff, "design X" is never actually asking you to design X. It's asking you to demonstrate that you can turn an ambiguous goal into a set of concrete, defensible engineering decisions — and that you understand why each decision was made, not just that it works.

A system design exercise is really testing four things:

1. Can you scope an ambiguous problem? Real prompts ("design Twitter") are deliberately underspecified. The first move is always to narrow it, not to start drawing boxes.
2. Do you know the actual trade-offs? Not "NoSQL is fast," but why a specific database's specific consistency model fits this specific access pattern.
3. Can you estimate? Rough math — requests per second, storage growth, bandwidth — tells you whether a design is even in the right order of magnitude before you commit to it.
4. Do you design for failure, not just the happy path? Every real system loses a node, a network link, or an entire data center eventually. A design that only works when everything is healthy isn't a design.

A useful reframe: you are not designing a correct system — there usually isn't one. You're picking a point on a curve (cost vs. latency, consistency vs. availability, simplicity vs. scale) and being able to defend why that point, for these requirements.

Why "it depends" is the correct starting answer

Nearly every system design question has the honest answer "it depends on the requirements" — and that's not a cop-out, it's the actual skill. A chat app with 10,000 users and a chat app with 500 million users are different systems, not the same system at a different scale. The rest of this chapter is about pinning down which system you're actually building before you design it.