A Simple Framework for System Design Interviews

System design interviews are open-ended by design. You are given a vague prompt, such as "design a URL shortener" or "design a chat app", and there is no single correct answer. Candidates who do well are rarely the ones who have memorised the most architectures. They are the ones who work through the problem in a clear order and explain why they make each choice.

The following five steps work for most prompts. Interviews usually run 45 to 60 minutes, so keep each step brief.

1. Clarify requirements

Spend the first five minutes asking questions instead of drawing. Who uses the system? What are the three or four most important features? What is out of scope? Separate functional requirements (what the system does) from non-functional ones (how well it does it): latency, availability, consistency, durability and cost.

Write the agreed requirements down. You will refer back to them when you justify decisions later.

2. Estimate the scale

Rough numbers shape every later decision. Estimate daily active users, requests per second, the ratio of reads to writes, and how much data you store over a few years. Precision is not the goal; the right order of magnitude is.

Example: a URL shortener with 100 million new links a month is about 40 writes per second on average. If reads are 100 times more frequent, that is around 4,000 reads per second. At roughly 500 bytes per record, five years of links is around 3 TB. Those numbers tell you that one database can hold the data, but reads should come from a cache.

3. Sketch the high-level design

Draw the main components and the path of a request: clients, a load balancer, application servers, a database, and a cache or queue if you need one. Walk through one read and one write from start to finish. Define the main API endpoints and the key data model, which tables or collections you need and what the primary keys are.

Keep this version simple and correct. Do not add components you cannot justify.

4. Go deep on the hard parts

Every system has one or two genuinely difficult problems. For a URL shortener, it is generating unique short codes without collisions. For a news feed, it is deciding between computing the feed when someone posts or when someone reads it. For chat, it is delivering messages in order to users on different servers.

Pick the hard parts yourself, or ask the interviewer which they want to explore. Then compare at least two options and state the trade-off. For instance: a counter-based ID is simple but needs coordination across servers, while random IDs avoid coordination but need collision checks.

Interviewers are not grading the boxes you draw. They are grading the reasons behind them.

5. Address failure and wrap up

Go back through your design and ask what happens when each part fails. What if a server dies, the database is unreachable, the cache is cold, or an entire data centre goes offline? Mention replication, backups, retries with backoff, and how you would monitor the system: latency, error rates and queue depth. Close with a short summary of the main decisions and what you would improve with more time.

Common mistakes

• Naming technologies such as Kafka, Redis or Cassandra before establishing why you need them.
• Skipping the estimate, then choosing a design that is far too large or too small.
• Designing everything in equal depth instead of focusing on the hard part.
• Staying silent while thinking. Explaining your reasoning out loud is part of what is being assessed.

The five steps: clarify requirements, estimate scale, sketch the design, go deep on the hard parts, then cover failure and summarise.