System design interview prep: structure and common topics

Use a consistent framework for every question

Interviewers at companies like Google, Meta, Amazon, and their equivalents in the UK and Australia follow a rubric. They want to see that you can scope a problem, make trade-offs explicit, and arrive at a defensible design. A consistent framework stops you from jumping straight to databases or microservices before you understand what you are building.

The most widely used structure has four stages: clarify requirements, estimate scale, design the system, then discuss trade-offs and failure modes. Spend roughly the first five minutes on requirements alone. Interviewers will often let you go off track just to see whether you self-correct.

1. Clarify functional and non-functional requirements (5 minutes)
2. Estimate scale: users, requests per second, storage over five years (5 minutes)
3. Draw the high-level design: clients, load balancers, services, databases, caches (20 minutes)
4. Deep-dive into one or two components the interviewer cares about (15 minutes)
5. Discuss trade-offs, bottlenecks, and how the system handles failure (5 minutes)

How to clarify requirements without wasting time

Ask three to five targeted questions, not ten. Focus on what changes the architecture. For a URL shortener, the key questions are: how many URLs per day, do shortened links expire, do we need analytics? For a ride-sharing service, ask about real-time location updates, matching latency, and whether drivers and riders are in the same region.

Separate functional requirements (what the system does) from non-functional requirements (how well it does it). Non-functional requirements drive most of the interesting design decisions. Common ones to confirm: availability target (99.9% versus 99.99%), read-to-write ratio, acceptable latency, and whether consistency or availability takes priority under a partition.

• Functional: core features the system must support
• Non-functional: latency, throughput, availability, durability, consistency
• Constraints: budget, team size, existing infrastructure (ask if relevant)
• Out of scope: name what you are not designing to show you can prioritise

Back-of-envelope estimation

Estimation shows you can reason about scale before committing to a design. You do not need exact numbers. You need an order of magnitude. A common starting point: assume 100 million daily active users, 10 requests per user per day, which gives roughly 10 billion requests per day or about 115,000 requests per second at peak.

Storage estimates follow the same logic. If each record is 1 KB and you store 10 million records per day, that is 10 GB per day or about 3.6 TB per year. These numbers tell you whether a single relational database is enough or whether you need sharding, object storage, or a distributed file system.

Common system design topics and what to know about each

Certain problems appear across almost every company's interview loop. Knowing the canonical design for each one, and the two or three decisions that define it, is more useful than memorising every component in a textbook.

• URL shortener: hash function choice, collision handling, redirect latency, analytics pipeline
• Rate limiter: token bucket versus sliding window, where to store state (Redis), distributed coordination
• News feed or timeline: fan-out on write versus fan-out on read, celebrity user problem, caching strategy
• Chat or messaging: WebSockets versus long polling, message ordering, delivery guarantees, storage per conversation
• Search autocomplete: trie versus inverted index, prefix caching, personalisation layer
• Distributed key-value store: consistent hashing, replication factor, quorum reads and writes, compaction
• Video streaming: CDN placement, adaptive bitrate, chunked upload, metadata service
• Notification service: push versus pull, fan-out at scale, deduplication, retry logic

How to talk about trade-offs

The trade-off discussion is where senior candidates separate themselves. Do not just describe what you chose. Explain what you gave up and why that is acceptable given the requirements you clarified at the start.

A useful template: 'I chose X over Y because our read-to-write ratio is 100:1, which means the extra write cost of X is worth the lower read latency. If write volume grew significantly, I would revisit this.' This shows you understand the design is conditional, not absolute.

Common trade-off pairs to be ready for: SQL versus NoSQL (schema flexibility versus ACID guarantees), synchronous versus asynchronous processing (latency versus throughput), strong consistency versus eventual consistency (correctness versus availability), monolith versus microservices (simplicity versus independent scaling).

Practice with real-time feedback

Reading about system design is not the same as doing it under interview conditions. You need to practise speaking your reasoning aloud while drawing a diagram, because silence for more than 30 seconds reads as uncertainty to most interviewers.

Break-In Bad's on-screen interview assistant listens to the interviewer's questions in real time and surfaces relevant prompts only you can see, even on a shared screen. For system design rounds, this means you can stay on track with the framework without losing your place when an interviewer asks an unexpected follow-up about, say, how your cache handles invalidation.

What to do in the two weeks before your interview

Two weeks is enough time to build solid coverage if you are deliberate. Aim to work through eight to ten full designs, not just read about them. For each one, write out the requirements, estimate scale, draw the diagram, and say the trade-offs out loud.

1. Week one: cover URL shortener, rate limiter, news feed, and chat system in full
2. Week one: review the CAP theorem, consistent hashing, and SQL versus NoSQL decision criteria
3. Week two: cover video streaming, search autocomplete, notification service, and a distributed key-value store
4. Week two: do two timed mock sessions of 45 minutes each with a partner or tool that gives feedback
5. Day before: review your framework steps and the estimation constants, then rest