System design interview questions ask you to architect a product under vague requirements, then defend trade-offs. Exponent frames a typical session as 45–60 minutes. Indeed and prep sites list classics (TinyURL, Instagram, chat, crawler). What searchers need is not another 40-item dump: a repeatable answer framework, core building blocks, and worked answers you can adapt. This guide gives you that kit.
TL;DR
- Use one framework every time: clarify → estimate → high-level design → deep dive → trade-offs.
- Non-functionals (latency, availability, consistency) drive architecture choices.
- Master building blocks: load balancers, caches, databases, queues, CDNs, sharding.
- Practice high-frequency prompts: URL shortener, news feed, chat, rate limiter, crawler.
- Talk trade-offs out loud; interviewers score reasoning more than a perfect diagram.
What a system design interview is
You receive an open-ended prompt (“Design a URL shortener,” “Design a notification system”). You define requirements, sketch components, discuss data flow, scaling, and failure modes. Coding is usually secondary; APIs and schemas often appear. Pair this round with coding and behavioral prep from interview questions and answers and behavioral interview questions.
The answer framework (use this every time)
Adapted from common prep structures (including Exponent’s five-step arc):
| Phase | Minutes (approx.) | What to do |
|---|---|---|
| 1. Clarify | 5–8 | Functional + non-functional requirements; out of scope |
| 2. Estimate | 3–5 | Users, QPS, storage, bandwidth (order of magnitude) |
| 3. High-level | 8–12 | Boxes and arrows: clients, APIs, services, data stores |
| 4. Deep dive | 15–20 | Hottest paths: schema, consistency, caching, sharding |
| 5. Trade-offs | 5–8 | Bottlenecks, failure modes, what you’d do with more time |
Clarifying questions cheat sheet
Who are the users? Read vs write ratio?
Mobile / web / both? Global traffic?
Consistency needs (strong vs eventual)?
Latency targets? Availability target?
Must we support search, analytics, admin tools?
What is explicitly out of scope for this interview?
State assumptions aloud when the interviewer stays vague.
Core non-functional requirements
| Concern | Plain meaning | Levers |
|---|---|---|
| Scalability | Grow with load | Horizontal scale, partitioning |
| Availability | Stay up when parts fail | Replication, failover, graceful degradation |
| Latency | Time to respond | Caching, CDNs, efficient queries |
| Throughput | Requests or events per second | Async processing, batching |
| Consistency | How fresh / agreed data is | Quorums, transactions, eventual sync |
| Durability | Data not lost | Replication, backups, write-ahead logs |
You rarely optimize all at once. Name the priority for this product.
Essential building blocks
Load balancer. Distributes traffic across app instances. Health checks remove bad nodes.
Cache (Redis/Memcached). Speeds hot reads. Decide TTL, invalidation, and stampede protection.
Database. SQL for relational integrity and flexible queries; NoSQL when access patterns are fixed and scale is extreme. Many designs use both.
Object storage. Blobs (images, videos) live outside the primary DB.
CDN. Edge caches for static and some dynamic content; cuts latency globally.
Message queue / pub-sub. Decouples producers and consumers (Kafka, SQS, Pub/Sub). Essential for feeds, notifications, async fan-out.
Search index. Elasticsearch/OpenSearch when DB LIKE queries will not scale.
Rate limiter. Protects APIs from abuse; token bucket / sliding window patterns.
For production architecture patterns, skim Google Cloud Architecture Center and AWS Well-Architected. CDN and edge concepts are well explained in Cloudflare Learning Center.
Capacity estimation (back-of-envelope)
Interviewers care that you try:
DAU × actions_per_user × bytes_per_action ≈ daily write volume
peak QPS ≈ average QPS × peak multiplier (often 2–5×)
storage ≈ daily bytes × retention_days × replication_factor
Round aggressively. “About 10K QPS at peak” beats fake precision.
Classic question 1: Design a URL shortener (TinyURL)
Clarify. Create short links, redirect to long URLs, optional custom aliases, analytics?, expiry?
Estimate. Say 100M new URLs/month ≈ ~40 writes/sec average; reads dominate (100:1). Store ~500 bytes/record metadata.
APIs.
POST /api/v1/urls { long_url, custom_alias?, ttl? } → { short_code }
GET /{short_code} → 302 Location: long_url
High-level. Client → LB → URL service → DB (short_code → long_url). Cache hot redirects. Optional analytics pipeline via queue.
Deep dive: ID generation.
| Approach | Pros | Cons |
|---|---|---|
| Hash long URL | Simple | Collisions; hard custom length |
| Base62 encode unique ID | Compact, sortable | Needs ID generator (DB sequence / Snowflake) |
| Random string + uniqueness check | Easy | Retry on collision |
Trade-offs. Cache redirects heavily. Handle deleted/expired links. For custom aliases, enforce uniqueness and abuse checks. Analytics can be eventual via async events.
Classic question 2: Design a news feed (Instagram-style)
Clarify. Follow graph, reverse chrono vs ranked, media, celebrities with huge fanout?
High-level. Post service, graph service, feed service, media store + CDN, cache.
Fan-out strategies.
| Strategy | How | When |
|---|---|---|
| Fan-out on write | Push post IDs to followers’ feed caches | Normal users, bounded fanout |
| Fan-out on read | Pull from followees at read time | Celebrities; avoid write storms |
| Hybrid | Push for most; pull for mega-followers | Realistic large systems |
Deep dive. Feed cache as ordered lists per user. Ranked feeds need a ranking service and feature store; start with chrono if time is short. Media never lives only in the primary DB.
Trade-offs. Freshness vs cost of push. Consistency of “seen” state. Hot partitions on celebrity accounts.
Classic question 3: Design a chat / messaging system
Clarify. 1:1 vs groups, delivery receipts, offline messages, encryption?, media?
High-level. Websocket gateway for online users, message service, presence service, store for history, push notifications for offline.
Data model sketch.
Conversation { id, type, member_ids }
Message { id, conversation_id, sender_id, body, created_at, status }
Trade-offs. Ordering per conversation, at-least-once vs exactly-once delivery semantics (usually at-least-once + idempotency), fan-out for large groups via queues.
Classic question 4: API rate limiter
Clarify. Limit per user, IP, or API key? Distributed? Exact vs approximate?
Approaches. Token bucket, leaky bucket, fixed/sliding window counters in Redis.
High-level. Gateway or sidecar checks Redis counters before forwarding. Return 429 with retry headers.
Trade-offs. Strong consistency of counts vs performance; local counters with periodic sync under-count/over-count under failure.
More high-frequency prompts (answer sketches)
Web crawler. Frontier queue of URLs, politeness delays per host, dedup with bloom filter or URL store, workers fetch and parse, store documents, respect robots.txt.
Notification system. Event in → preference service → fan-out to email/push/SMS providers via queues; template service; retry with dead-letter queues.
Recommendation system. Candidate generation → ranking → re-ranking; online vs offline features; start with popularity + collaborative filtering before deep ML.
Ride sharing / maps. Geospatial indexing, matching service, ETA, surge; different consistency needs for location pings vs trip billing.
SQL vs NoSQL, sync vs async (decision table)
| Need | Lean toward |
|---|---|
| Multi-row transactions, joins | SQL |
| Massive simple key lookups | KV / wide-column |
| Spiky fan-out work | Async queues |
| User waiting on response | Sync path + careful timeouts |
| Global low latency reads | CDN + regional replicas |
How to practice
- Pick 8 prompts; timebox 45 minutes each with a friend or rubber duck.
- Draw on a whiteboard or blank doc; narrate constantly.
- After each session, write three trade-offs you missed.
- Study failure modes: cache stampede, hot keys, split brain, backlog explosions.
Career foundation if you are still leveling into these loops: how to become a software engineer.
Common mistakes
- Jumping to Kafka and Kubernetes before requirements
- Never estimating scale
- Ignoring failure and partial outages
- Silent diagramming for ten minutes
- Claiming “we’ll shard” without a shard key story
Whiteboard checklist (print this)
Before you say “done”:
- [ ] Functional requirements listed
- [ ] Non-functionals prioritized (pick top 2)
- [ ] Rough QPS and storage stated
- [ ] API signatures sketched
- [ ] Primary data model named
- [ ] Cache and async boundaries explained
- [ ] One failure scenario walked through
- [ ] One explicit trade-off articulated
If time remains, discuss monitoring (metrics, logs, traces) and rollback strategy. Interviewers notice when you care about operability.
Sample 10-minute high-level for a rate limiter (narration)
“I’ll assume we protect a public HTTP API per API key at 100 requests/minute, distributed across many gateway nodes, approximate counts OK. Clients hit an API gateway that calls a Redis-backed limiter before the app. Each key has a sliding window counter; on exceed we return 429 with Retry-After. I’ll deep dive on sliding window vs token bucket and on Redis failure modes next.”
That narration shows structure even before boxes are perfect.
Consistency models in one minute
| Model | User-visible meaning | Typical use |
|---|---|---|
| Strong | Reads see latest committed write | Bank balances, inventory hard locks |
| Eventual | Reads may lag; converges | Social counts, timelines |
| Read-your-writes | A user sees their own updates | Profile edits |
Say which model your design needs. Blindly claiming strong consistency everywhere is a red flag.
Leveling hints
Junior loops may stop at a correct high-level and basic deep dive. Mid-level should own capacity math and failure modes. Senior/staff should drive trade-offs, multi-region thoughts, and migration plans from an existing system. Match depth to the level on the req. Coding interview prep still matters in parallel via interview questions and answers.
Run it on Parlel
Map system-design practice to roles that actually ask for it.
target_roles: SWE / platform / backend postings with system design rounds
prep: 2 timed designs per week from this question set
digest: weekly matching mid/senior eng roles
Digest shape: { role, company, level_signal, matched_skills }. Find targets on /jobs and /explore.
Keep reading
Frequently asked questions
What is a system design interview?
A 45–60 minute (typical) conversation where you architect a system from an open-ended prompt and explain components, data flow, scaling, and trade-offs.
How do you answer system design interview questions?
Clarify requirements, estimate scale, propose a high-level design, deep dive on critical paths, then discuss bottlenecks and trade-offs.
What are the most common system design interview questions?
URL shortener, social news feed, chat/messaging, web crawler, rate limiter, notification system, and recommendation system appear repeatedly across prep sites.
What topics should I study for system design interviews?
Caching, load balancing, databases, replication, sharding, queues/pub-sub, CDNs, consistency models, and failure handling.
Do system design interviews require coding?
Usually not full implementations. Expect APIs, schemas, and clear component reasoning. Some loops add light coding or SQL.
How long is a typical system design interview?
Often about 45–60 minutes, though companies vary. Pace yourself with the five-phase framework above.