A system design interview framework you can run in 45 minutes

The template at a glance

For a 60-minute round, give the extra time to the deep dive. For a 35-minute round, shrink estimates to a minute and go straight from requirements to the diagram.

Step 1: Requirements (and scope)

Start by restating the problem, then ask questions that change the design. Good questions are about who uses it, what they do most, how many, and what matters most (latency, consistency, availability, cost).

• Functional: list the three to five features you'll design for. Explicitly park the rest ("I'll leave search and admin tools out unless you want them").
• Non-functional: pick the two or three qualities that will drive decisions, for example "reads must be fast, writes can be eventually consistent".
• Scale: daily active users, read/write ratio, data size, and geographic spread.

The common mistake is asking twenty questions. The interviewer wants to see that you can find the questions that matter, not that you can stall.

Step 2: Back-of-the-envelope estimates

Turn the scale into a few numbers: requests per second at peak, storage over a few years, and anything that looks dangerous (a fan-out factor, a hot key, bandwidth for media). Round hard; you're looking for orders of magnitude. Then say what the numbers mean: "100k reads/s means we need caching in front of the database" is worth more than the arithmetic. The full method is in back-of-the-envelope estimation.

Step 3: API and data model

Sketch the main endpoints (or events) with their inputs and outputs. This pins down what the system actually does and often reveals missing requirements. Then list the core entities, their primary keys, and the access patterns ("we always look up by short code", "we read a user's latest 20 posts"). Access patterns drive the database choice and the partition key far more than the entity list does.

Step 4: High-level design

Draw the simplest architecture that satisfies every functional requirement: clients, a load balancer, a few services, the data stores, caches, and queues. Walk one request end to end for each main use case (write path, read path). Keep it simple; you'll add complexity in the deep dive where it's justified.

A useful checklist of building blocks to consider (not to include by default):

• Load balancers (L4 for long-lived connections, L7 for HTTP routing).
• Caches (CDN for static and edge content, Redis/Memcached for hot data; cache-aside is the default pattern). See caching strategies.
• Databases: relational when you need transactions and flexible queries; key-value or wide-column when access is by key at large scale.
• Queues/logs (Kafka, SQS) to decouple slow or bursty work from the request path.
• Object storage for files and media, served via CDN.
• Sharding by a key that spreads load evenly and matches the main access pattern; consistent hashing to rebalance. See sharding and consistent hashing.
• Replication for availability and read scaling, with a stated consistency model. See consistency models and CAP.

Step 5: Deep dive

Pick the one or two parts that are genuinely hard for this problem, or let the interviewer pick. Typical deep dives:

• ID generation and hot-key handling in a URL shortener.
• Fan-out strategy and the celebrity problem in a news feed.
• Connection management and ordering in a chat app.
• Atomic counters and failure modes in a rate limiter.
• Retries, idempotency, and priority isolation in a notification system.

Depth means: the algorithm or schema, what happens under concurrency, what happens when a component fails, and how it behaves at 10× the load.

Step 6: Trade-offs and wrap-up

Trade-offs are the single strongest seniority signal. For each major decision, name the alternative and why you didn't choose it: SQL vs NoSQL, push vs pull, strong vs eventual consistency, synchronous vs asynchronous, build vs buy. Close with the bottlenecks you'd watch, how you'd monitor the system, and what you'd improve with more time.

What changes with seniority

• Mid-level: a correct, complete high-level design with sensible components and some depth when prompted.
• Senior: drives the conversation, chooses the deep dives, raises failure modes and trade-offs without being asked.
• Staff and above: connects technical choices to cost, operability, team ownership, migration paths, and how the system evolves over years.

Common mistakes

1. Jumping to a diagram before agreeing on requirements.
2. Naming technologies ("use Kafka") without saying what property you need from them.
3. Designing for the average load instead of the peak.
4. Going silent while thinking; narrate your reasoning.
5. Running out of time before discussing a single trade-off.

Some companies split design into product-flavoured and infrastructure-flavoured rounds; Meta's product architecture vs system design is the best-known example.