12 Common System Design Interview Questions (and How to Approach Each)

System design interviews feel open-ended, but the questions themselves are remarkably repetitive. The same dozen problems appear across companies — and each one is really a vehicle for one or two specific trade-offs. Recognise which, and the round stops feeling like improvisation.

For each question below: what to clarify, the core components, and the deep dive the interviewer is usually waiting for. For the building blocks themselves, keep the system design cheat sheet open.

The framework (use it every time)

1. Requirements: functional, non-functional, out of scope.
2. Estimates: reads/writes per second, storage per year, bandwidth.
3. API: the handful of endpoints that matter.
4. Data model: entities and the database choice.
5. High-level design: clients, load balancer, services, stores, caches, queues.
6. Deep dive: the one hard part of this problem.
7. Trade-offs and bottlenecks: what breaks at 10x, and what you'd change.

1. Design a URL shortener (like bit.ly)

• Clarify: custom aliases? expiry? analytics? read-to-write ratio (very read-heavy).
• Core: write service generates a short code → key-value store; read path with a cache in front; 301/302 redirect.
• Deep dive: ID generation — base62 over a counter (needs a distributed counter or pre-allocated ranges) vs. hashing (collisions). Cache hot links.

2. Design a rate limiter

• Clarify: per user, per IP or per API key? hard or soft limits? distributed?
• Core: middleware or gateway check against a shared counter store (Redis).
• Deep dive: algorithm — fixed window (bursty at edges), sliding window log (accurate, memory-heavy), sliding window counter, token bucket (allows bursts). Atomicity with Lua scripts or atomic increments; what happens when Redis is down (fail open vs. closed).

3. Design a chat application (like WhatsApp)

• Clarify: one-to-one and groups? online status? read receipts? message history?
• Core: persistent connections (WebSockets) to a gateway tier, a service that routes messages, a message store, push notifications for offline users.
• Deep dive: connection management and ordering — which gateway holds a user's connection, per-conversation sequence numbers, delivery acknowledgements, and group fan-out.

4. Design a news feed (like Instagram or LinkedIn)

• Clarify: chronological or ranked? how many followers can one account have?
• Core: post service, follow graph, feed service, feed cache.
• Deep dive: fan-out on write vs. fan-out on read — precompute feeds for normal users, but pull posts for celebrity accounts at read time (a hybrid).

5. Design a notification system

• Clarify: channels (push, SMS, email)? priority? user preferences and quiet hours?
• Core: API → queue → per-channel workers → third-party providers; a preferences store; a template service.
• Deep dive: reliability — retries with backoff, idempotency keys so users don't get duplicates, dead-letter queues, and rate limits per provider.

6. Design file storage (like Dropbox or Google Drive)

• Clarify: max file size? sync across devices? sharing? versioning?
• Core: metadata service + database, blob storage for chunks, sync service, notification of changes.
• Deep dive: chunking and deduplication — split files into chunks, hash them, upload only changed chunks; conflict handling when two devices edit offline.

7. Design search autocomplete

• Clarify: how many suggestions? personalised? latency budget (very low)?
• Core: trie or prefix index of popular queries, built offline from logs; served from memory with caching.
• Deep dive: freshness vs. speed — rebuild the top-k per prefix periodically instead of computing at query time; sharding the trie by prefix.

8. Design a ride-hailing service (like Uber or Ola)

• Clarify: matching, pricing, tracking — which are in scope?
• Core: driver location updates, a geospatial index, a matching service, trip service, payments.
• Deep dive: geospatial indexing — geohashes or quadtrees for "drivers near me", handling a very high rate of location writes, and avoiding double-assigning a driver.

9. Design video streaming (like YouTube)

• Clarify: upload and playback? live or on-demand?
• Core: upload service → transcoding pipeline (multiple resolutions) → object storage → CDN; metadata service.
• Deep dive: adaptive bitrate streaming and CDN caching — segmenting videos (HLS/DASH), and the cost of storing many renditions.

10. Design a web crawler

• Clarify: scale, politeness rules, what to store?
• Core: URL frontier (queue), fetchers, parser, dedup store, content storage.
• Deep dive: politeness and deduplication — per-host rate limiting and robots.txt, URL normalisation, content hashing to avoid storing duplicates.

11. Design a distributed cache

• Clarify: eviction policy, consistency needs, size?
• Core: cache nodes, a client library, consistent hashing.
• Deep dive: consistent hashing and invalidation — minimising reshuffling when nodes join/leave, hot keys, write-through vs. write-back vs. cache-aside.

12. Design a payment system

• Clarify: which flows — charge, refund, payout? external gateways?
• Core: payment service, ledger, gateway integrations, reconciliation job.
• Deep dive: correctness over speed — idempotency keys, a double-entry ledger, exactly-once effects despite retries, and reconciliation with the bank.

How to practise

• Do each question out loud in 45 minutes with a timer.
• Write your estimates down; interviewers love seeing numbers drive decisions.
• For every design, answer: "What breaks first at 10x traffic?"

Related reading

• The system design interview cheat sheet
• 15 DSA patterns for coding interviews
• What FAANG and top India tech loops look like
• System design interview: the complete guide
• Design a payment system (UPI) and a video streaming service