Common Interview Questions and Solutions
Why Catalog Matters
While every system design interview is unique, certain questions appear with remarkable consistency across companies. This isn’t random—these questions survive because they’re exceptional at testing your understanding of core concepts.
Here’s the secret: once you’ve designed a URL shortener, you understand key generation, redirection, and analytics. Once you’ve built a social media feed, you grasp fan-out, ranking, and celebrity scaling problems. These patterns repeat across dozens of different systems. The goal of this section isn’t memorization—it’s pattern recognition.
By working through the canonical problems, you build a mental library of solution patterns. In your actual interview, when you encounter a novel system, you’ll think: “This is similar to the feed problem, so I’ll apply that pattern.”
The Major Categories
System design questions cluster into predictable buckets. Recognizing which bucket your question falls into is half the battle.
┌─────────────────────────────────────────────────────────────────┐
│ System Design Question Categories │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. DATA-INTENSIVE SYSTEMS │
│ Social feeds, notifications, messaging │
│ Focus: Scale, denormalization, eventual consistency │
│ │
│ 2. INFRASTRUCTURE SYSTEMS │
│ CDN, load balancer, cache layer │
│ Focus: Distribution, routing, failover │
│ │
│ 3. REAL-TIME SYSTEMS │
│ Chat, live streaming, collaborative editing │
│ Focus: Low latency, ordering, connection management │
│ │
│ 4. SEARCH & RANKING SYSTEMS │
│ Search engine, autocomplete, recommendation │
│ Focus: Indexing, ranking algorithms, relevance │
│ │
│ 5. STORAGE SYSTEMS │
│ File sharing, video streaming, photo hosting │
│ Focus: Durability, efficient serving, transcoding │
│ │
│ 6. TRANSACTIONAL SYSTEMS │
│ Payment processing, booking, ride-sharing │
│ Focus: Consistency, idempotency, reconciliation │
│ │
└─────────────────────────────────────────────────────────────────┘Each category has different demands and solutions. Learn the patterns in each.
Eight Canonical Problems (With Solutions)
1. Design a Social Media Feed
What Makes This Hard
- Users follow hundreds of people; each generates multiple posts daily
- “Feed” is personalized for each user; can’t precompute everyone’s feed
- Read traffic dwarfs write traffic (1000:1 or higher)
- New posts should appear within seconds (low latency)
- Billions of potential feed reads; needs extreme scale
Key Requirements
- 100M daily active users, 50M posts/day
- Feed read latency under 200ms (p99)
- New posts visible within 5 seconds
- Consistent view for the same user, eventual consistency across users
Core Challenges
- Fan-out problem: When a celebrity posts, millions of followers see it. Do you write once and fan-out to all followers (fan-out on write), or read at query time (fan-out on read)?
- Ranking: Chronological order isn’t engaging; you need relevance ranking
- Hotspot handling: Celebrity posts hit specific shards hard
Recommended Architecture
- Store posts in a time-series database (e.g., Cassandra) keyed by (post_id, timestamp)
- Use fan-out on write for normal users (write to each follower’s feed cache), fan-out on read for celebrities (read from followers list at query time)
- Cache recent feeds in Redis (24-hour TTL)
- Use a machine learning model to rank feed results (engagement, recency, relationships)
Critical Trade-offs
- Fan-out on write: simpler reads, complex writes, high storage (fan-out on read: complex reads, simple writes, lower storage)
- Real-time ranking adds latency; pre-computed rankings are stale
- Caching trades consistency (might show stale posts) for speed
2. Design a Messaging System (Chat)
What Makes This Hard
- Messages must arrive in order; if user A sends two messages, user B must see them in that order
- Delivery must be reliable (user B should get all messages, not miss any)
- Thousands of concurrent connections; each message is small but numerous
- Low latency critical (users expect near-instant delivery)
Key Requirements
- 500k concurrent users
- Message delivery within 100ms (p99)
- Exactly-once delivery semantics (no duplicates, no loss)
- Message ordering per user pair
Core Challenges
- Connection management: Maintaining 500k open WebSocket connections requires load balancing and sticky sessions
- Message ordering: Distributed systems struggle with ordering; you need a total order across servers
- Exactly-once delivery: Network failures and server crashes create duplicates; idempotency keys are essential
Recommended Architecture
- Use WebSockets for real-time bidirectional communication
- Central message queue (e.g., Kafka) as source of truth with partition per user pair (ensures ordering)
- Cache recent messages in Redis for quick access
- Sticky load balancing: route each user to same server when possible (reduces reconnect overhead)
- Use idempotency keys; clients attach unique ID to each message
Critical Trade-offs
- WebSockets are complex and require connection management; polling is simpler but higher latency
- Ordering requires partitioning; this makes scaling individual conversations harder
- Exactly-once delivery requires coordination; at-least-once is simpler but requires idempotency
3. Design a Video Streaming Platform (Like YouTube)
What Makes This Hard
- Videos are massive (2GB to 10GB); can’t fit in memory
- Network bandwidth is the constraint; most users have slow/variable connections
- Videos must play smoothly despite varying network conditions
- Encoding/transcoding takes hours for large files
Key Requirements
- 100M daily active users, 500 hours of video uploaded daily
- Play video smoothly on 1mbps and 50mbps connections
- Codec conversion to multiple formats (MP4, WebM, HLS)
- Global delivery with low latency
Core Challenges
- Transcoding bottleneck: Converting raw video to multiple formats is CPU-intensive and takes hours
- Adaptive bitrate: Serve different quality based on connection speed (1080p on fiber, 360p on mobile)
- Storage and delivery: Exabytes of video globally; CDN critical
Recommended Architecture
- Async transcoding pipeline: upon upload, queue video in transcoding job queue; return immediately to user
- Multiple output formats: MP4 (progressive download), HLS/DASH (adaptive streaming)
- Store original and transcoded versions in object storage (S3)
- Distribute via CDN (Cloudflare, Akamai); edge caches videos
- Adaptive bitrate player: client monitors bandwidth, requests appropriate quality
Critical Trade-offs
- Transcoding immediately vs lazily (immediate: better user experience, high cost; lazy: cheap, bad experience for unpopular videos)
- Store all formats vs compute on-demand (all formats: more storage, instant playback; compute: less storage, delays)
- One global CDN vs regional CDNs (global: simpler; regional: lower latency but more operational burden)
4. Design a Ride-Sharing Service (Like Uber)
What Makes This Hard
- Real-time spatial matching (find nearby drivers)
- ETA calculation must be fast (user sees result in 1 second)
- Surge pricing adjusts in real-time based on demand
- Consistency concerns (driver can’t accept same ride twice; payment must be atomic)
Key Requirements
- 1M active drivers, 10M active riders
- Match ride in under 5 seconds
- ETA accurate within 1 minute
- Handle 100k concurrent ride requests
Core Challenges
- Geospatial queries: Standard databases aren’t optimized for “find all drivers within 2km of this location”
- Real-time updates: Driver locations change constantly; broadcasting these updates is high-volume
- Matching logic: Which driver should get this ride? (Closest? Best rating? Surge-adjusted earnings?)
Recommended Architecture
- Geospatial indexing: use PostGIS (PostgreSQL extension) or specialized store (Redis geospatial) for location queries
- Real-time location updates via WebSocket; location service broadcasts updates to interested subscribers
- Payment service with strict consistency: transactional database for money; no eventual consistency
- Surge pricing calculated every 5 minutes per zone; cached and served from memory
Critical Trade-offs
- Centralized matching (one service decides) vs distributed (drivers pull available rides): centralized is simpler, distributed scales better
- Real-time locations vs periodic updates: real-time is accurate but high bandwidth; periodic is cheaper
- Complex matching algorithm vs simple (closest): simple is faster but worse user experience
5. Design a Payment System
What Makes This Hard
- Money is involved; errors are catastrophic
- Idempotency critical: network failure shouldn’t charge user twice
- Reconciliation: payments must balance; no money can disappear
- High throughput at low latency
Key Requirements
- Process 1M transactions/day
- Transaction latency under 2 seconds
- Zero tolerance for data loss
- Exactly-once payment processing
Core Challenges
- Exactly-once semantics: Network failures, server crashes, timing issues can create duplicates
- Distributed transactions: Multiple parties involved (user account, merchant account, payment processor); must all succeed together
- Reconciliation: Verify that every transaction was recorded correctly in all systems
Recommended Architecture
- Idempotency keys: each payment request has unique ID; if request arrives twice, database constraint prevents duplicate charge
- Transaction log (event store): immutable record of every payment
- Saga pattern for distributed transaction: break payment into steps (debit user → credit merchant → emit events); if any step fails, compensate
- Reconciliation job: batch process runs nightly, verifies payment records match across systems
Critical Trade-offs
- Strongly consistent payment processing (must verify before returning) vs weakly consistent (return immediately, verify later): consistent is safer, slower
- Complex distributed transaction coordination vs simple (don’t refund until next morning): simple is faster, requires customer trust
6. Design a Web Crawler
What Makes This Hard
- Internet is vast; millions of websites, billions of pages
- Crawling is slow; visiting every page takes months
- Politeness matters: don’t hammer servers with requests
- Deduplication: don’t crawl same page twice
Key Requirements
- Crawl 1B web pages
- Respect robots.txt and rate limits
- Deduplicate: never visit same URL twice
- Coordinate across multiple crawler instances
Core Challenges
- URL frontier: Which pages to crawl next? Some are important (news sites), some are spam
- Politeness: How many requests can you send to each domain without being rude? (Typically 1 request/second)
- Deduplication at scale: 1B URLs; checking if you’ve seen each one is expensive
Recommended Architecture
- URL frontier using a queue (Kafka, RabbitMQ): stores unvisited URLs prioritized by importance
- DNS cache: looking up domain every time is slow; cache DNS results
- Bloom filter for deduplication: probabilistic data structure; uses little memory, very fast lookups
- Distributed crawlers: multiple machines each pull from queue, crawl pages, emit new URLs
Critical Trade-offs
- Crawl depth (how deep in each site) vs breadth (how many sites): breadth captures more variety, depth is thorough but time-consuming
- Politeness vs speed: respecting rate limits slows you down
- Bloom filter (false positives possible) vs exact deduplication: Bloom filter is faster
7. Design a Key-Value Store (Like Redis)
What Makes This Hard
- In-memory storage is limited; need eviction policies
- Replication must stay in sync across multiple nodes
- Consistency: what happens when network splits?
- High throughput (100k requests/sec)
Key Requirements
- Sub-millisecond latency for get/set
- Handle 100k requests/sec
- Replicate to backup node
- Survive single node failure
Core Challenges
- Consistent hashing: When you add new nodes, you need to rebalance keys; consistent hashing minimizes keys moved
- Replication lag: Primary writes quickly; replica catches up asynchronously; reads from replica might see stale data
- Split-brain: Network partition; primary and replica can’t communicate; who’s in charge?
Recommended Architecture
- Consistent hashing: map keys to nodes; when nodes change, keys are redistributed smoothly
- Primary-replica replication: writes go to primary, then replicate to backup
- Sentinel or cluster mode for failover: if primary dies, promotion to replica is automatic
- Eviction policy (LRU, LFU): when memory is full, delete least important keys
Critical Trade-offs
- Strong consistency vs availability: if primary and replica disagree, do you serve potentially stale data or reject requests?
- Synchronous replication (safe, slow) vs asynchronous (fast, risky): lose data if primary crashes before replica receives update
8. Design a Collaborative Editor (Like Google Docs)
What Makes This Hard
- Multiple users editing simultaneously; changes conflict
- Order of operations matters: if Alice inserts “a” and Bob inserts “b”, does result end with “ab” or “ba”?
- Offline editing: user edits while disconnected; must merge with server when online
- Seconds of latency compound; feels slow
Key Requirements
- Support 100 concurrent editors on one document
- Resolve conflicts automatically (no manual merge)
- Low latency updates (under 500ms)
- Offline editing support
Core Challenges
- Conflict resolution: Two users edit simultaneously; must converge on same final state
- Operational transformation (OT) vs CRDT: OT is complex but proven; CRDT is mathematically elegant but less common
Recommended Architecture
- CRDT (Conflict-free Replicated Data Type): each operation is designed to commute (order doesn’t matter for final result)
- Central server maintains canonical document state
- Clients send operations to server; server broadcasts to all clients
- Offline queue: local operations applied optimistically; synced with server when reconnected
- Cursor tracking: broadcast cursor positions so users see where others are editing
Critical Trade-offs
- OT (simpler reasoning, more infrastructure) vs CRDT (complex math, works offline): choose based on team expertise
- Operational latency (compute final state from all operations) vs caching (cache state, sync incrementally): caching is faster
Pattern Recognition Across Problems
You’ll notice themes repeating:
| Pattern | When Needed | Implementation |
|---|---|---|
| High write throughput | Social feeds, messaging, events | Use queue (Kafka); batch writes |
| Fast reads | All systems | Cache layer (Redis) + CDN for static |
| Real-time updates | Chat, collaborative editing, location | WebSocket + pub/sub system |
| Geospatial queries | Ride-sharing, maps | PostGIS or specialized index |
| Ordering guarantees | Chat, payments, messaging | Partition by entity; process sequentially |
| Exactly-once semantics | Payments, critical operations | Idempotency keys + deduplication |
| Massive scale | Social media, YouTube | Distributed system; sharding; eventual consistency |
Once you recognize which patterns apply, design becomes systematic rather than ad-hoc.
Your Interview Timeline (45-60 Minutes)
Manage your time like this:
Minutes 0-5: Clarify Requirements
- Ask questions before designing
- Confirm numbers: users, requests/sec, data volume
- Confirm constraints: latency targets, consistency requirements
- Write down agreed-upon requirements
Minutes 5-10: High-Level Estimation
- How many requests per second?
- How much data storage needed?
- Rough capacity numbers guide architecture
- Is this a scale problem or complexity problem?
Minutes 10-25: High-Level Architecture
- Draw boxes and arrows (not implementation details yet)
- Identify major components: APIs, databases, caches, queues
- Explain data flow: where does request go? how is response built?
- Get interviewer agreement before diving deeper
Minutes 25-40: Deep Dive
- Pick one or two areas and zoom in
- Database schema, indexes, query patterns
- How do you handle failure? What if X breaks?
- Trade-off discussion: why this choice over alternatives?
- Don’t try to design everything; pick the interesting parts
Minutes 40-45: Q&A and Clarifications
- Interviewer asks challenging questions
- Stay flexible; adjust design if new constraints emerge
- Show your reasoning, not memorized answers
Pro Tip: Interviewers care more about how you think than what you know. Don’t memorize the exact database choice for each problem. Learn the reasoning process, and apply it.
What Interviewers Look For
Beyond correctness, they’re evaluating:
- Communication clarity — Can you explain complex ideas simply? Do you draw diagrams?
- Tradeoff awareness — Do you understand what you’re giving up? Can you articulate why?
- Requirement clarity — Did you ask questions, or jump to conclusions?
- Scale thinking — Do your designs handle the numbers? Or will they break at 10x load?
- Failure modes — What breaks? How do you recover?
- Adaptability — When requirements change, can you adjust your design?
These matter more than remembering the exact architecture for a URL shortener.
Red Flags to Avoid
Things that hurt your score:
- Premature optimization — Designing for 1B users when the requirement is 1M
- Ivory tower design — “Ideally we’d use X” without considering operational reality
- No tradeoff discussion — Presenting one solution as universal
- Ignoring failure modes — “We’ll just use Redis” without discussing what happens if it crashes
- Overcomplicating early — Jumping to microservices when monolith would work
- Not asking questions — Making assumptions about requirements
- Talking at the interviewer — Treating it as a presentation, not a conversation
Closing Thoughts: From Theory to Practice
You’ve now completed the journey from understanding what system design is (Chapter 1) through the fundamentals of designing real systems (Chapters 2-22) to articulating designs in interviews (Chapters 23).
This book has given you frameworks: how to estimate capacity, choose technologies, think about consistency, scale databases, build for reliability. But frameworks are just scaffolding. The real skill comes from practice.
Here’s what to do next:
- Pick one of the eight canonical problems above
- Spend 45 minutes designing it (with timer)
- Record yourself; watch it back
- Did you clarify requirements? Discuss tradeoffs? Handle edge cases?
- Repeat with different problems
Do this 10-20 times, and you’ll be ready. Not because you’ve memorized architectures, but because you’ve internalized the thinking process.
The beauty of system design is that it’s learned through doing, not through reading. This book has given you the concepts. Now go build—and interview.
Good luck.