System design interview cheat sheet

Building blocks and when to reach for them

Most designs are assembled from the same small kit. Know what each piece does and the specific problem it solves, so you add it for a reason rather than out of reflex.

Load balancer

Spread traffic across stateless app servers (L4 for raw throughput, L7 for routing on path/header). Adds horizontal scale and a single health-checked entry point.

CDN

Serve static assets and cacheable responses from the edge, close to users. Cuts latency and origin load; the first reach for any global, read-heavy, media-serving system.

Cache (Redis / Memcached)

Put hot reads in memory in front of the database. Decide a policy: cache-aside is the default; choose an eviction strategy (LRU) and a TTL, and have an answer for stale data and cache stampedes.

Message queue (Kafka / SQS / RabbitMQ)

Decouple producers from consumers and absorb write spikes. Turns a synchronous, fragile path into an async, retryable one; the backbone of most write-heavy and event-driven designs.

Database replication

Add read replicas to scale reads and improve availability. Be explicit about replication lag and that replicas are eventually consistent.

Sharding / partitioning

Split data across nodes when one machine cannot hold or serve it. Pick a shard key that spreads load evenly and avoids hotspots; consistent hashing limits reshuffling when nodes change.

Rate limiter

Protect the system from abuse and overload. Token bucket is the usual answer; place it at the edge or in a shared store so the limit holds across servers.

Choosing a database

Pick storage from the access pattern, not from familiarity. Say what you are optimising for and which store fits, then name the cost.

The trade-offs interviewers listen for

The component is the easy half; the trade-off is what earns the senior signal. For every choice you make, say what you are giving up.

CAP theorem

During a network partition you must choose between consistency and availability; you cannot have both. Most user-facing systems pick availability and accept eventual consistency (AP); systems like payments and inventory pick consistency (CP).

Consistency models

Strong consistency means every read sees the latest write (simpler to reason about, harder to scale). Eventual consistency means reads may briefly be stale (cheaper, more available). State which you choose and why for each data path.

SQL vs NoSQL

SQL gives transactions, joins, and a fixed schema; NoSQL gives horizontal scale and schema flexibility. The honest answer is usually 'SQL until the access pattern or scale forces a specific NoSQL store', not a blanket preference.

Latency vs throughput

Latency is how long one request takes; throughput is how many you handle per second. Batching and queues raise throughput at the cost of per-request latency; optimise for whichever the requirements name.

Push vs pull (fan-out)

Fan-out-on-write (push) precomputes feeds for fast reads but is expensive for users with millions of followers. Fan-out-on-read (pull) is cheaper to write but slower to read. Real systems use a hybrid: push for normal users, pull for celebrities.

Frequently asked questions

How do I structure a 45-minute system design interview?

Spend the first five minutes clarifying functional and non-functional requirements, five on back-of-the-envelope scale estimates, five sketching the API, five to ten on the data model and storage choice, ten on the high-level diagram, and the rest on one or two deep dives the interviewer steers you toward. The single biggest mistake is jumping to a diagram before agreeing on scope and scale, because every later decision depends on those numbers.

Do I need to memorise the latency numbers?

You do not need them to the nanosecond, but you should know the orders of magnitude: memory is nanoseconds, SSD is microseconds, a same-datacenter round trip is sub-millisecond, and a cross-continent round trip is over a hundred milliseconds. These ratios are what let you justify a cache or a CDN with real reasoning instead of hand-waving, which is exactly what interviewers are listening for.

What separates a senior answer from a junior one?

Juniors describe components; seniors name trade-offs. A strong answer does not just say 'add a cache' - it says why, which eviction policy, what the staleness window is, and what happens on a cache miss or a stampede. Seniors also scope ruthlessly, estimate before designing, and proactively identify the system's bottleneck rather than waiting to be asked. The cheat sheet above is the vocabulary; the seniority is in the justification.

Is a system design round only for senior engineers?

It is most heavily weighted for senior and staff loops, but plenty of mid-level loops now include a scaled-down design round, and new-grad loops sometimes include a lightweight one. Even if your target level does not formally test it, the thinking - estimating scale, choosing storage, naming trade-offs - makes you better in the coding and behavioural rounds too, so it is rarely wasted preparation.