System Design Interview Guide
A repeatable structure for system design rounds, the building blocks interviewers expect you to reach for, and worked examples.
A four-step structure for the round
Most design interviews run 45 minutes. This split keeps you from spending thirty of them on the whiteboard before anyone has agreed what you are building.
- 1
Requirements and scope
Pin down what the system must do and at what scale before drawing anything. Most failed design rounds skip this.
- How many users, and how many active?
- Read-heavy or write-heavy?
- Latency targets?
- What can be eventually consistent?
- 2
High-level design
Clients, services, storage and the data flow between them. Name the APIs and the core entities.
- What are the main endpoints?
- What are the core entities?
- Which components exist?
- How does a request flow?
- 3
Deep dive
Pick the two components that matter most and go deep: storage choice, scaling strategy, caching, partitioning. Say why, and what you gave up.
- Which database, and why?
- How does it scale horizontally?
- What is cached, and how is it invalidated?
- How is the data partitioned?
- 4
Scale and failure
Where does it break at ten times the load, and what happens when a component dies?
- What is the bottleneck?
- What fails over, and how?
- Where are the hot spots?
- What do you monitor?
Building blocks to know
You will reach for most of these in any design. Know what each one costs as well as what it gives.
Load balancing
Spread traffic across servers
L4 vs L7, round robin, consistent hashing
Database scaling
Grow storage and throughput
Replication, sharding, partitioning
Caching
Serve reads without hitting storage
Redis, Memcached, cache invalidation
Message queues
Decouple and process asynchronously
Kafka, RabbitMQ, SQS
CDN
Serve static content near the user
Edge caching, cache headers
Consistency
What every reader is allowed to see
CAP, ACID vs BASE, quorums
Problems to practise
Six classics, each built around a different bottleneck. Work them in this order.
URL shortener
Hashing, key generation, redirects at scale
Social feed
Fan-out, timeline storage, ranking
Photo sharing
Media storage, CDN, feed
Messaging app
Delivery guarantees, presence, encryption
Video streaming
Transcoding, adaptive bitrate, CDN
Ride matching
Geospatial indexing, matching, ETA
Work each one against the clock and out loud. Then rehearse with a technical practice interview that follows up on your design with the “why?” questions a panel asks.
Frequently asked questions
- Who gets system design interviews?
- Mid-level engineers usually get a shorter version; senior, staff and engineering-manager loops almost always include a full 45-to-60-minute round.
- How is a system design round scored?
- On the process more than the diagram: whether you clarified requirements, made a reasonable high-level design, went deep where it mattered, and named the trade-offs. A perfect architecture presented without reasoning scores worse than a good one with it.
- How do I practise system design?
- Work through the classic problems above with the four-step structure and a timer, out loud. Then rehearse with someone — or an AI interviewer — who will interrupt with "why?" the way a real panel does.