What System Design Actually Tests (Interviews and Real Work)

What System Design Actually Tests (Interviews and Real Work)

System design has a reputation for being about memorizing a reference architecture — "here's how you build Twitter" — and reciting it back. That's not what it tests, in an interview or in a real job. It tests whether you can take an ambiguous, underspecified problem and make defensible trade-offs under constraints that are never fully known upfront. There is rarely one correct answer. There are answers that are well-reasoned for the stated requirements and answers that aren't.

The Framework That Actually Matters

Before you draw a single box, you need two things nailed down: functional requirements (what does the system do — post a photo, send a message, look up a price) and non-functional requirements (how well does it need to do it — how many users, what latency is acceptable, does it need strong consistency or is eventual fine, what's the read/write ratio). Most weak system-design answers skip straight to "we'll use a load balancer and a cache" without ever pinning down whether the system needs to handle 100 requests/day or 100,000 requests/second — and those two numbers lead to completely different architectures.

Interview System Design vs. Real System Design

In an interview, you start from a blank whiteboard with a made-up scale number and 45 minutes. In a real job, you inherit a system that already has users, already has data, already has technical debt, and the "requirements" are a half-written product spec plus three conflicting opinions from stakeholders. Real system design work happens mostly in design docs (often called RFCs) that get reviewed and argued over before any code is written, and it gets revisited constantly as actual production numbers replace the estimates you made on day one.

Why This Path Is Structured the Way It Is

Every module after this one builds toward the same skill: given a set of requirements, reason about the trade-offs of each component you add, and be able to say why you chose one option over another — not just name the option. By the time you reach the "Designing Real Systems" module, you'll be applying this framework to actual case studies (a URL shortener, a chat app, a news feed) the same way you'd approach a real design doc.

What "Good" Actually Looks Like

A strong system-design answer sounds less like "we use Redis for caching" and more like "we cache read-heavy, rarely-changing data in Redis because our read:write ratio is roughly 20:1, and the staleness window from a 60-second TTL is acceptable for this use case — if it weren't, we'd need write-through invalidation instead." The difference is not vocabulary. It's demonstrated reasoning.