Why system design mattersCore idea
Every FAANG company (Google, Amazon, Meta, Apple, Microsoft) has a system design round for mid-level and senior engineering roles. It checks whether you can think about a whole system, make trade-offs and explain your decisions clearly. A strong design round can make up for a weaker coding round, and the other way round.
The questions test breadth more than depth in one algorithm. Interviewers want to see you reason about real systems under real limits: time, budget and team size.
%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","actorBkg":"#e7f5ff","actorBorder":"#1e1e1e","noteBkgColor":"#fff9db","noteBorderColor":"#1e1e1e"}}}%%
graph LR
U["Users"] --> CDN["CDN"]
U --> LB["Load balancer"]
LB --> A1["App server"]
LB --> A2["App server"]
A1 --> C["Cache"]
A2 --> C
A1 --> DB[("Database")]
A2 --> DB
A1 --> Q["Message queue"]
Q --> W["Workers"]
class U blue
class CDN,LB orange
class A1,A2 green
class C yellow
class DB violet
class Q,W grey
classDef orange fill:#ffd8a8,stroke:#1e1e1e,color:#1e1e1e
classDef blue fill:#a5d8ff,stroke:#1e1e1e,color:#1e1e1e
classDef green fill:#b2f2bb,stroke:#1e1e1e,color:#1e1e1e
classDef red fill:#ffc9c9,stroke:#1e1e1e,color:#1e1e1e
classDef violet fill:#d0bfff,stroke:#1e1e1e,color:#1e1e1e
classDef yellow fill:#ffec99,stroke:#1e1e1e,color:#1e1e1e
classDef grey fill:#e9ecef,stroke:#1e1e1e,color:#1e1e1eCore concepts every engineer must knowCore idea
Scalability
Scalability is handling more load by adding resources. Vertical scaling means a bigger machine (more CPU and RAM). Horizontal scaling means more machines. Modern systems almost always prefer horizontal scaling because there is no hard ceiling.
Availability
Availability is the share of time a system is working. It is counted in “nines”. Reaching five nines takes redundant components, automatic failover and health checks at every layer.
| Availability | Name | Downtime per year |
|---|---|---|
| 99.9% | three nines | ~8.76 hours |
| 99.99% | four nines | ~52.6 minutes |
| 99.999% | five nines | ~5.26 minutes |
Reliability
Reliability is the chance that a system does its job correctly over a period of time. A reliable system gives correct results even when parts of it fail, thanks to redundancy, error handling and graceful degradation (switching off non-essential features instead of failing completely).
Latency and throughput
Latencyhow fast
The time one request takes to go from client to server and back.
Throughputhow many
How many requests the system handles per second.
The two often pull against each other: tuning for low latency can cost throughput, and the reverse. The goal is to get both good enough within your limits.
How to approach a system design interviewHow it works
A clear structure shows engineering maturity. Follow these four steps:
Clarify requirements
Ask about scale (daily active users, queries per second), features (core vs nice-to-have) and constraints (budget, timeline).
High-level design
Sketch the major components: clients, load balancers, app servers, databases, caches, message queues.
Deep dive
Pick 2–3 critical areas and go deep: the database schema, API design, caching strategy or data partitioning.
Trade-offs
Say what you are optimising for and what you are giving up. Think in trade-offs, not absolutes.
Common system design topicsTopics
Interviewers draw from a predictable set of problems:
URL Shortener
Hashing, base62 encoding, analytics, fast redirects.
Chat System
WebSockets, message ordering, presence, delivery guarantees.
News Feed
Fan-out strategies, ranking, caching.
Rate Limiter
Token bucket, sliding window, rate limiting across many servers.
Search Autocomplete
A trie, real-time updates, ranking suggestions.
What interviewers evaluateIn the interview
Common mistakesPitfalls
Frequently asked questionsFAQ
What is system design in a software engineering interview?
System design is the process of defining a system's architecture, components, interfaces, and data flow so it meets stated functional and non-functional requirements. In interviews it means designing a large-scale distributed system for millions of users. Interviewers score breadth of reasoning: requirements clarification, component choice, deep dives on 2-3 areas, and explicit trade-offs.
How much of a system design interview should be spent clarifying requirements?
Roughly the first 10 to 15 minutes. A strong candidate spends the opening minutes pinning down daily active users, requests per second, read-to-write ratio, and which features are core versus nice-to-have, before sketching any architecture. Skipping this step is the most common mistake, because every later decision about caching, sharding, or queues depends on the numbers you establish first.
How is system design different from data structures and algorithms?
Data structures and algorithms test depth on a single problem with a known answer, while system design tests breadth across many technologies with no single correct answer. DSA rounds are objective and 45 to 60 minutes of coding. System design rounds are conversational, typically 45 minutes. You are judged on how you reason about constraints, scale, and failure.
Now explain what is system design? to me out loud
I'll give you a design problem and push on the trade-offs, like a real interviewer.