High-level design, deep dives and trade-offs

The high-level design needs to work end to end. It doesn't need to be optimized. The deep dives are where the interview is decided. They take about fifteen minutes, and they are where the interviewer learns how deeply you understand the system.

The high-level design

A typical skeleton: clients, then a load balancer or API gateway, then stateless services, then databases, caches and queues. Name the services after what they do, such as "post service" or "fan-out workers", not after the technology.

Walk each functional requirement through the boxes, out loud. For example: "A user creates a post. The request hits the post service, which writes the post to the posts table. Media was already uploaded straight to S3 with a presigned URL. The service publishes a PostCreated event to Kafka. Fan-out workers consume it..." Narrating each flow catches missing arrows, and it lets the interviewer interrupt early if you misread something.

Choosing deep dives

Good deep-dive candidates usually come from the non-functional requirements:

• The hottest path at peak. Cache design, hot keys, or a celebrity problem.
• A correctness invariant. No double booking, no double charge, message ordering.
• A scaling wall from your numbers. Sharding a 5 TB table, or 250,000 location writes a second.
• A failure mode. The cache cluster dies, a region goes down, or a payment provider times out.

Pick two or three. Protect the time for them.

The method for each deep dive

Use the same four moves every time.

1. State the problem with a number.
2. Offer two or three options.
3. Compare them on the axes that matter for this system, then pick one.
4. Say what you give up.

Here is a worked example. "Writing 100 million timeline entries when a celebrity posts would take minutes, and it would burn most of our write capacity. Options: push anyway with throttling, pull at read time, or a hybrid. I'll use the hybrid. Push for accounts under about 100,000 followers, and pull and merge for the rest. The cost is an extra read and merge on each feed load. We can absorb that, because a celebrity's recent posts form a small, hot cache key."

The deep-dive patterns page maps recurring hard problems to their standard solutions.

Closing with the wrap-up

Spend the last two minutes on what you know is weak. For example: "The biggest risks are the fan-out backlog during spikes and the single Kafka cluster. Next I'd add per-region cells, monitoring on fan-out lag, and a backfill job that rebuilds timelines from the posts table." This shows judgment, and it gives the interviewer an easy final question.

Driving the conversation

You are expected to drive the interview.

• State assumptions out loud. "I'll assume eventual consistency is fine for like counts."
• Offer options, then commit. "Option A is simpler, but needs a lock per seat. Option B avoids contention but adds a queue. With 10,000 people hitting the same seats in the first minute, I'll take B."
• Check in at major boundaries, not every thirty seconds. "Does fan-out or storage matter more to you?"

When the interviewer pushes back, treat it as information. "Good point, that breaks if the cache is cold. Let me fix it" scores better than defending a weak choice.

Common mistakes

• Listing options and never choosing. The choice and its cost are the signal.
• Defending a weak choice under pushback. Adjust, and say why.

Check yourself

1. You reach minute 30 with no deep dive. What do you say? "The rest is standard. Let me go deep on the fan-out path." Then do it, and keep the wrap-up short.

2. What makes a deep dive strong? It states the problem with a number, compares options on the axes that matter, picks one, and says what it costs.

Key takeaways

• The design must work end to end first. Optimize in the deep dives.
• Pick two or three deep dives from the requirements, and protect their time.
• Use the four moves: problem with a number, options, comparison and choice, cost.
• Close with the weakest parts and what you would do next.

Further learning

The deep-dive patterns page is the next step. Use it to build a list of standard solutions you can reach for under time pressure.

Next, see how interviewers judge all of this in what interviewers score.