System Design Interview Questions — A Framework That Works

System design rounds feel open-ended, but interviewers are grading a fairly fixed set of things: can you scope a problem, reason about trade-offs, and drive a discussion. A framework keeps you from freezing on the blank whiteboard.

A 6-step framework

1. Clarify requirements (3–5 min). Functional ("users can shorten a URL and get redirected") and non-functional ("100M reads/day, p99 < 100ms, highly available"). Write them down. Ask before you build.
2. Estimate scale. Back-of-envelope: reads/writes per second, storage per year, bandwidth. This drives every later decision.
3. Define the API. A handful of endpoints. It forces concreteness.
4. High-level design. Boxes and arrows: clients → load balancer → service → data store → cache. Get the happy path working first.
5. Deep-dive on 1–2 components. The interviewer will steer you. Common ones: the data model, the caching strategy, how you shard, how you handle hot keys.
6. Address bottlenecks & trade-offs. Single points of failure, consistency vs. availability, read vs. write optimization.

Spend most of your time in steps 4–6. Steps 1–3 are the setup that earns you the right to make good decisions later.

Building blocks you must be fluent in

• Load balancing — round-robin vs. least-connections; L4 vs. L7.
• Caching — where (client, CDN, app, DB), eviction (LRU), and invalidation. "There are only two hard problems…"
• Databases — SQL vs. NoSQL, indexing, replication, and sharding strategies (hash vs. range).
• Replication & consistency — leader/follower, quorums, and the CAP trade-off in plain language.
• Message queues — decoupling, smoothing spikes, async processing (Kafka, SQS).
• CDNs — pushing static and cacheable content to the edge.

If you can explain when and why to reach for each, you'll handle most prompts.

Common questions

• Design a URL shortener (the classic warm-up — hashing, key generation, redirect path, cache).
• Design a news feed (fan-out on write vs. read, the celebrity problem).
• Design a chat app (websockets, presence, message ordering, delivery guarantees).
• Design a rate limiter (token bucket, where it lives).
• Design a ride-sharing / nearby-search service (geospatial indexing, quadtrees/geohash).
• Design a typeahead / autocomplete (tries, ranking, caching).

What interviewers actually reward

• Driving the conversation. Don't wait to be asked — propose, then check in.
• Naming trade-offs out loud. "I'll denormalize here to make reads fast, at the cost of write complexity." That sentence pattern is gold.
• Numbers. Tie decisions back to your scale estimate.
• Knowing what you're not optimizing. "For v1 I'll skip multi-region; here's where I'd add it."

What sinks candidates: jumping to a complex design before scoping, going silent, or refusing to make a decision when there's no perfect answer.

How to prepare

Read a couple of solid references, then talk through designs out loud — system design is a spoken skill, and silent reading doesn't build it. Whiteboard 8–10 classic problems end to end, narrating every trade-off. Practising the verbal flow with live structure feedback helps you catch the moments you go quiet or skip the scale estimate.

---

Pair this with the software engineer interview prep guide for the coding and behavioral rounds.