System Design Interview Frameworks That Actually Survive Follow-Up Questions

Why most candidates fail system design interviews

The system design interview is the round where the most strong engineers get rejected for reasons that don't show up in their actual engineering work. The pattern is consistent: a good engineer hears "design Twitter" and starts drawing boxes. The interviewer starts asking pointed follow-ups. Within ten minutes the candidate is defending architectural choices they made before they understood the problem, and the rest of the interview is spent retroactively justifying decisions instead of demonstrating reasoning.

The fix isn't more knowledge of distributed systems. The fix is a framework that forces the candidate to slow down and define the problem before solving it. The framework is well-known to senior engineers but routinely abandoned under pressure: requirements first, capacity second, then data model, API, architecture, and scale, in that order.

The rest of this post walks through each step.

Step 1: Requirements

When the interviewer says "design X," your first move is not to start drawing. Your first move is to ask clarifying questions until you understand what you're building.

Ask:

Spend two to three minutes here. The interviewer is taking notes on whether you scoped before solving. Candidates who don't scope lose points before they've drawn anything.

• What are the core features? "Design Twitter" could mean tweet creation and feed display. It could mean tweet creation, feed display, follower graph, search, notifications, direct messages, and trending topics. The scope changes the answer entirely. Pin down the core feature set in the first two minutes.
• Who are the users? Public consumers? Internal employees? Other systems? The user characterization shapes everything from the read/write ratio to the SLA expectations.
• What's the read-to-write ratio? A tweet system is read-heavy (most users browse more than they post). A logging system is write-heavy. The ratio shapes whether you optimize for read or write throughput.
• What's not in scope? Just as important. "We don't need to handle images for now" or "auth is out of scope" lets you focus on the parts that matter.

Step 2: Capacity estimation

Once you know what you're building, estimate the order of magnitude of the workload. This is where most candidates skip ahead and where senior interviewers most often catch them.

Estimate:

These estimates inform every subsequent decision. If your capacity calculation says you'll have 10 million writes per second, you're not going to use a single Postgres instance, and the architecture you draw needs to reflect that. If the calculation says 100 writes per second, you can use a much simpler stack and you should not over-engineer.

The failure mode: skipping capacity entirely and proposing an architecture that's either wildly over-engineered or unable to handle the load. Either way, the interviewer's notes will say "didn't reason about scale," which is the specific signal they're scoring against.

• Daily active users. If the question is about a known service, ballpark the public number. If it's a hypothetical, use the user characterization from step 1.
• Requests per second. DAU multiplied by average actions per user per day, divided by seconds in a day. Walk through the arithmetic out loud — interviewers want to see the calculation, not just the conclusion.
• Storage. Average payload size times the rate of new content. Project out one to three years.
• Bandwidth. Read RPS times average response size.

Step 3: Data model

Define the entities and their relationships before you talk about how they're stored. This is the step that separates engineers who think structurally from engineers who jump to implementation.

For each entity: - What are the fields? - What are the relationships to other entities? - What's the access pattern (read by ID, read by query, write-once, append-mostly)?

The access pattern is the part most candidates skip. It's the part that determines whether the entity belongs in a relational database, a key-value store, a document store, or a wide-column store. Don't pick the storage technology first — pick the access pattern first, and let the access pattern drive the storage choice.

• What are the fields?
• What are the relationships to other entities?
• What's the access pattern (read by ID, read by query, write-once, append-mostly)?

Step 4: API design

Before drawing the architecture, sketch the API. What endpoints does the client call? What are the inputs and outputs? What's the authentication model?

This step is short — three to five minutes — but it forces clarity about the boundary between the system you're designing and the world that uses it. Candidates who skip this often draw architectures that don't actually map to the operations the client needs to perform.

For each endpoint, name the HTTP method, the path, the request body, the response format, and the expected latency budget. Latency budgets are the part most candidates forget — they shape every architectural decision downstream.

Step 5: Architecture

Now you can draw boxes. Show the major components — load balancer, application servers, caches, databases, message queues, asynchronous workers — and how requests flow between them.

Walk through a single request end-to-end: client makes a call, hits the load balancer, routes to an application server, looks up cached data, falls through to the database if needed, returns the response. Then walk through a write: client posts data, the write hits the application server, gets persisted, optionally enqueues a downstream event for processing.

The interviewer is watching for whether your architecture matches the capacity estimates from step 2. If you said 10 million RPS earlier and you're now drawing a single Postgres instance, the interviewer will catch the mismatch. Don't let them — make sure your component choices reflect the scale you estimated.

Step 6: Scale and trade-offs

The final step is identifying the bottlenecks in your architecture and explaining how you'd handle them.

For each major component, ask: - What happens when this component is the bottleneck? - How would you scale it (vertical, horizontal, sharding, caching)? - What's the trade-off (consistency vs availability, latency vs cost, complexity vs simplicity)?

Senior interviewers specifically probe trade-offs. The right answer is not "I'd shard the database" — the right answer is "I'd shard the database by user ID, which means cross-user queries become harder, but that's okay because the access pattern is mostly per-user reads, and the trade-off is justified by the scale."

The depth of trade-off reasoning is the part that distinguishes senior candidates from mid-level candidates in system design rounds. Don't propose solutions without naming the trade-offs you're accepting.

• What happens when this component is the bottleneck?
• How would you scale it (vertical, horizontal, sharding, caching)?
• What's the trade-off (consistency vs availability, latency vs cost, complexity vs simplicity)?

How real-time coaching helps with system design

The hardest part of system design under pressure is sticking to the framework instead of diving into architecture. Cornerman recognizes the start of a system design question and surfaces a cue with the framework reminder. A cue like "System design — requirements first, then capacity, then data model" is ten words. It's not an answer. It's the structural reminder that keeps you from skipping straight to drawing boxes.

For mid-question rescue, Cornerman also recognizes specific common pitfalls and surfaces shorter cues — "name the read/write ratio," "estimate RPS first," "cache or queue here?" — that nudge you back into structured thinking when you start drifting.

For the deeper take on coding and system design coaching, see how Cornerman works for software engineers.