The 6-step framework for any system design question
- →Clarify requirements (3–5 min): who uses it, the core features, and what is out of scope. Ask about scale — daily users, reads vs writes, latency targets.
- →Estimate scale: requests per second, storage per year, bandwidth. Rough numbers are fine; the point is to show which part of the system will be under pressure.
- →Define the API: the 3–5 endpoints or events the system exposes. This keeps the rest of the design honest.
- →Draw the high-level design: clients → load balancer → stateless services → cache → database, plus queues for anything slow.
- →Deep-dive the hardest part: the data model, the hot path, or whatever the interviewer steers you to. Pick a database and say why.
- →Discuss bottlenecks and trade-offs: single points of failure, sharding, replication lag, consistency vs availability, and what you'd monitor.
Most-asked system design questions
1.Design a URL shortener (like bit.ly)
Read-heavy (≈100:1). Generate short codes with base62 encoding of a unique ID (from a counter service or pre-generated key ranges) to avoid collisions. Store code → URL in a key-value store, cache hot codes in Redis, and serve 301/302 redirects from the edge. Discuss custom aliases, expiry, and click analytics written asynchronously through a queue.
2.Design a chat application (like WhatsApp)
Persistent WebSocket connections held by a fleet of connection servers; a session service maps user → server. Messages go through a queue, are stored per conversation (wide-column store such as Cassandra, partitioned by chat ID), and fan out to online recipients; offline users get push notifications. Cover delivery receipts, ordering per conversation, group fan-out and end-to-end encryption at a high level.
3.Design a news feed (like Instagram or X)
The key choice is fan-out on write (push posts into followers' precomputed feeds — fast reads) vs fan-out on read (assemble at request time — cheap writes). Use a hybrid: push for normal users, pull for celebrities with millions of followers. Feeds live in a cache as lists of post IDs; posts and media live in separate stores with a CDN in front of media. Ranking can be a separate service.
4.Design a rate limiter
Compare token bucket (allows bursts, simple), leaky bucket (smooth output), and fixed/sliding window counters. Keep counters in Redis with atomic increments and TTLs so every API server shares state. Return HTTP 429 with a Retry-After header, and discuss limiting per user, per IP and per API key, plus what happens if Redis is unavailable (fail open vs fail closed).
5.Design a video streaming service (like YouTube or Netflix)
Uploads go to object storage, then a queue triggers transcoding into multiple resolutions and bitrates, chunked for adaptive streaming (HLS/DASH). A CDN serves the chunks close to viewers; metadata, search and recommendations are separate services. Discuss upload resumability, cost of storage per rendition, and pre-warming the CDN for popular content.
6.Design a ride-hailing service (like Uber or Ola)
Drivers send location every few seconds; store current positions in an in-memory geospatial index (geohash or quadtree) for nearby-driver lookups. A matching service offers the ride to nearby drivers with timeouts. Trips are a state machine (requested → accepted → in progress → completed) stored in a relational database for consistency. Mention surge pricing, ETA calculation and handling dropped connections.
7.Design a notification system
Producers publish events to a queue; a notification service applies user preferences, rate limits and templates, then hands off to channel workers (push, SMS, email) that call third-party providers with retries and exponential backoff. Store a log for idempotency so a retry never sends twice, and track delivery status per channel.
Concepts you should be able to explain in one minute
- →Horizontal vs vertical scaling, and why stateless services make horizontal scaling easy.
- →Caching strategies: cache-aside, write-through, TTLs, and cache invalidation.
- →SQL vs NoSQL: when you need transactions and joins vs when you need write throughput and flexible schemas.
- →Sharding and consistent hashing; replication (leader–follower) and replication lag.
- →CAP theorem in practice: during a network partition, choose consistency or availability.
- →Message queues (Kafka, SQS, RabbitMQ) for decoupling and absorbing spikes.
- →Load balancers, CDNs, and why latency to the user matters more than raw server speed.
Blank on the day?
Invisipilot listens to your live interview and shows a structured answer on your screen in seconds — built from your own resume and the role you're applying for. Works with Zoom, Google Meet and Teams, in the browser or as a Windows and Mac app.
Frequently asked questions
- How long should a system design answer take?
- Most rounds are 45–60 minutes. Spend about 5 minutes on requirements, 5 on estimates and the API, 15 on the high-level design and 15–20 on a deep dive and trade-offs. Leave time for the interviewer's follow-ups — they are part of the grade.
- Do freshers get system design questions?
- Usually a lighter version: low-level design (classes and objects for a parking lot or library system) or a simple high-level design like a URL shortener. Full distributed-system design is typical from around two years of experience.
- What is the biggest mistake in system design interviews?
- Jumping straight into drawing boxes without clarifying requirements and scale. The second biggest is naming technologies without saying why — every choice should come with the trade-off it makes.