System Design Interview Prep
Based on the HelloInterview curriculum. Each topic file follows the same structure: problem → requirements → core design → key decisions → security angle → interview tips.
How to Use
(foundations.md) before individual problems
start Easy → Medium → Hard
every design has a security section — always weave this into your answer
know latency/throughput/storage estimates cold (see foundations.md)
Reusable Requirements Cheat Sheet
Copy-paste these into any design. Most systems share ~80% of their requirements — the differentiator is the unique functional requirement and the dominant non-functional constraint.
Recurring Functional Requirements
These appear in almost every system. State them briefly, then move on to the unique ones.
Authentication & accounts
- Users can register, log in, log out
- Password reset via email
- Optional: OAuth (Sign in with Google/GitHub)
User profiles
- View and edit own profile
- View other users' public profiles
Notifications
- In-app notifications
- Optional: email/SMS/push notifications for important events
Search & discovery
- Search for content by keyword
- Optional: filters (by date, category, location)
Settings & preferences
- Users can configure notification preferences
- Users can delete their account (GDPR)
Admin / moderation
- Report and flag content
- Admin dashboard to review flagged content
Rate limiting
- API endpoints are rate-limited per user / IPRecurring Non-Functional Requirements
These appear in virtually every design. Know your numbers and state them with justification.
| Requirement | Typical values | What to say in an interview |
|---|---|---|
| Availability | 99.9% (8.7 hr/yr downtime) to 99.99% (52 min/yr) | "For a social app: 99.9%. For payments: 99.99%." |
| Read latency (P99) | < 100ms for API responses, < 10ms for cache-backed reads | "Reads under 100ms P99, served from cache wherever possible." |
| Write latency (P99) | < 500ms for mutations | "Writes async where possible; sync only for financial operations." |
| Durability | 99.999999999% (11 nines) for user data | "User data must never be lost — replicated across 3+ AZs." |
| Consistency | Depends on domain | "Eventual for feeds/social; strong for inventory/payments/reservations." |
| Scalability | Horizontal for stateless services | "Stateless services scale horizontally behind a load balancer." |
| Security | TLS, AuthN/AuthZ, rate limiting, audit log | Always mention these; they're table stakes. |
| Observability | Metrics, logs, traces, alerts | "Every service emits latency/error metrics; structured logs to SIEM." |
The Non-Functional That Defines the Design
Every system has one dominant non-functional requirement that forces the interesting design decisions. Identify it first.
| Dominant NFR | Systems that have it | Key design consequence |
|---|---|---|
| Low read latency | URL shortener, DNS, CDN | Cache everything; serve from edge |
| High write throughput | Activity feed, IoT sensors, ad clicks | Wide-column DB (Cassandra), log-based append |
| Strong consistency | Payments, inventory, reservations | Distributed transactions, two-phase commit, saga |
| Real-time delivery | Chat, live comments, auctions | WebSocket/SSE, pub/sub, fan-out |
| Large media / storage | YouTube, Dropbox, Instagram | Chunked upload, CDN, object storage |
| Geospatial queries | Uber, Yelp, Tinder | Geohash/quadtree index |
| Ordering & fairness | Auction bidding, trading, scheduler | Single-node sequencer or distributed lock |
| Approximate counts at scale | YouTube Top K, ad analytics | Count-Min Sketch, HyperLogLog |
Interview Delivery Framework (30-min format)
0-3 min → Requirements: functional + non-functional (scale, latency, availability)
3-5 min → Capacity estimation: QPS, storage, bandwidth
5-10 min → High-level design: main components on a whiteboard
10-20 min → Deep dive: the 2-3 interesting design problems in this system
20-25 min → Security, failure modes, trade-offs
25-30 min → Questions / clarificationsProblem Index
Easy
| Topic | Key Concepts | File |
|---|---|---|
| URL Shortener (Bitly) | Hashing, redirect, key generation, caching | url-shortener.md |
| File Storage (Dropbox) | Chunked upload, dedup, sync, CDN | file-storage-dropbox.md |
| Local Delivery Service | Geo-indexing, ETA, routing | local-delivery-service.md |
| News Aggregator | RSS/scraping, dedup, ranking, feed | news-aggregator.md |
Medium
| Topic | Key Concepts | File |
|---|---|---|
| Ticketmaster | Inventory lock, concurrency, seat reservation | ticketmaster.md |
| Facebook News Feed | Fan-out on write vs read, timeline, ranking | news-feed.md |
| Tinder | Geo-match, swipe, recommendation engine | tinder.md |
| LeetCode (Judge) | Code execution sandbox, queue, results | leetcode-judge.md |
| WhatsApp (Chat) | WebSocket, message delivery, E2E encryption | whatsapp-chat.md |
| Yelp (Nearby Search) | Geo-index, quadtree/geohash, reviews | yelp-nearby-search.md |
| Strava (Activity Tracking) | GPS ingestion, segments, leaderboards | strava.md |
| Distributed Rate Limiter | Token bucket, sliding window, distributed counters | rate-limiter.md |
| Online Auction | Bidding, real-time updates, consistency | online-auction.md |
| Facebook Live Comments | Fan-out, real-time, pubsub, ordering | fb-live-comments.md |
| Facebook Post Search | Search index, ranking, freshness | fb-post-search.md |
| Price Tracking Service | Scraping, change detection, alerting | price-tracking.md |
Hard
| Topic | Key Concepts | File |
|---|---|---|
| Media storage, feed, social graph scale | instagram.md | |
| YouTube Top K | Heavy hitters, Count-Min Sketch, streaming | youtube-top-k.md |
| Uber (Ride Sharing) | Location, dispatch, matching, ETA | uber-ride-sharing.md |
| Robinhood (Trading) | Order book, matching engine, real-time quotes | robinhood-trading.md |
| Google Docs (Collab Edit) | OT/CRDT, conflict resolution, real-time sync | google-docs.md |
| Distributed Cache | Consistent hashing, eviction, replication | distributed-cache.md |
| YouTube (Video Platform) | Transcoding pipeline, CDN, recommendation | youtube.md |
| Job Scheduler | DAG, workers, retry, at-least-once delivery | job-scheduler.md |
| Web Crawler | BFS/politeness, dedup, robots.txt, scale | web-crawler.md |
| Ad Click Aggregator | Stream processing, exact vs approx counts | ad-click-aggregator.md |
| Payment System | Idempotency, ledger, double-entry, saga | payment-system.md |
| Metrics Monitoring | Time-series DB, aggregation, alerting | metrics-monitoring.md |
| ChatGPT (LLM API) | Streaming inference, queuing, multi-tenant | chatgpt-llm-api.md |
Quick Concept Reference
| Problem Pattern | Key Technique | Systems |
|---|---|---|
| Fan-out write | Precompute feeds at write time | News Feed, Instagram |
| Fan-out read | Compute feed at read time (celebrities) | Twitter (hybrid) |
| Inventory lock | Optimistic locking / reservation TTL | Ticketmaster, Auction |
| Geo-proximity | Geohash / Quadtree | Uber, Yelp |
| Real-time push | WebSocket / SSE / Long-poll | WhatsApp, Live Comments |
| Heavy hitters | Count-Min Sketch, TopK heap | YouTube Top K |
| Deduplication | Bloom filter / hash fingerprint | Web Crawler, File Storage |
| Rate limiting | Token bucket / Sliding window | Rate Limiter, API GW |
| Idempotency | Unique request IDs + dedup table | Payments, Job Scheduler |
| Conflict resolution | OT / CRDT | Google Docs |
| Time series | RRD/TSDB, downsampling | Metrics Monitoring |
Condensed Scenario Reference
One-line condensed summary for every scenario: the unique functional requirement, the dominant non-functional constraint, and the single most important design decision. Use this for rapid review.
Easy
| Scenario | Core Functional (unique) | Dominant NFR | The Key Design Decision |
|---|---|---|---|
| URL Shortener | Create short code → redirect | Read latency < 10ms; 115k redirects/s | Counter + Base62 encoding for keys; cache all redirects in Redis (99% hit rate) |
| File Storage (Dropbox) | Upload, sync, share files; delta sync | Durability 11 nines; large file support (GBs) | Chunk files (4MB blocks) + content-addressed dedup; CDN for downloads |
| Local Delivery Service | Match riders/drivers; ETA; route | Low latency geo-queries (<50ms) | Geohash grid index in Redis; driver location updates every 5s |
| News Aggregator | Scrape RSS/web; dedup; rank; deliver | Freshness (new articles within minutes) | Crawler + message queue + dedup by URL hash + ranking by recency + engagement |
Medium
| Scenario | Core Functional (unique) | Dominant NFR | The Key Design Decision |
|---|---|---|---|
| Ticketmaster | Browse events; reserve seats; purchase | Strong consistency — no double-booking | Optimistic lock with reservation TTL (hold seat for 10 min, release if unpaid) |
| News Feed | Follow users; see their posts in ranked order | Fan-out scale for celebrity accounts | Push (fan-out on write) for normal users; pull for celebrities with 1M+ followers |
| Tinder | Swipe left/right; match on mutual like; chat | Low latency geo + preference matching | Precompute candidate pool per user; geohash for local queries |
| LeetCode Judge | Submit code; run against test cases; return results | Isolation + fairness + sandboxing | Queue submissions → isolated container per run (Docker/gVisor) → return results via WebSocket |
| WhatsApp Chat | Send/receive messages; delivery + read receipts; group chat | Real-time delivery; offline queuing | WebSocket per connection; message store per conversation (Cassandra); fan-out to group members |
| Yelp Nearby Search | Search businesses by location + filters + reviews | Geo-query latency < 50ms | Geohash or quadtree for spatial index; Elasticsearch for full-text + facets |
| Strava | Record GPS activities; segments; leaderboards | High write throughput (GPS points); ranking queries | Time-series DB for GPS points; precomputed segment efforts; Redis sorted set for leaderboard |
| Rate Limiter | Enforce per-client request limits; 429 on exceed | Decision latency < 5ms; distributed accuracy | Sliding window counter in Redis (2 integers per client); fail open if Redis down |
| Online Auction | Place bids; real-time current price; win at close | Strong consistency on bids; real-time | Serialized bid processing per auction; WebSocket for live price updates; auction close via cron |
| Facebook Live Comments | Post comments on live video; see others' comments in real-time | Fan-out to millions of concurrent viewers | Pub/sub with SSE/WebSocket; comment fan-out via Kafka; read from cache (not DB) |
| Facebook Post Search | Search posts by keyword; ranked by relevance + recency | Search freshness (new posts indexed quickly) | Elasticsearch index; async indexer via Kafka consumes new posts; re-rank by social signals |
| Price Tracking | Track product prices across retailers; alert on price drop | Freshness of prices (scrape frequency) | Scheduler + scraper pool; store price history (TimescaleDB); alert via queue on threshold breach |
Hard
| Scenario | Core Functional (unique) | Dominant NFR | The Key Design Decision |
|---|---|---|---|
| Post photos/videos; follow; feed; stories | Scale: 500M DAU; read-heavy; large media | Object storage (S3) + CDN; feed precomputed via fan-out on write; graph in separate service | |
| YouTube Top K | Return top-K trending videos over a time window | Approximate counts at billion-event scale | Count-Min Sketch for frequency estimation; TopK heap for top results; aggregate per shard |
| Uber Ride Sharing | Request ride; match driver; track; pay | Real-time geo matching < 1s; ETA accuracy | Driver location in Redis geo index; matching via proximity search + availability; ETA from routing engine |
| Robinhood Trading | Place orders; order book; real-time quotes | Strong ordering; no double-execution | Single-threaded matching engine per symbol; event sourcing for order book; WebSocket for live quotes |
| Google Docs | Multi-user real-time editing; no conflicts | Conflict-free concurrent edits | Operational Transformation (OT) or CRDT for merge; operational log per document; WebSocket sync |
| Distributed Cache | Get/set/delete; eviction; consistent distribution | Consistent key distribution across nodes | Consistent hashing ring; virtual nodes for balance; LRU eviction; replication factor = 3 |
| YouTube Platform | Upload video; transcode; stream; recommendations | High throughput transcoding; global CDN delivery | Async transcode pipeline (queue + workers per format); HLS chunked streaming; CDN edge caching |
| Job Scheduler | Schedule recurring and one-off jobs; retry on failure | At-least-once delivery; no double-execution | DAG of tasks; worker pool with lease/heartbeat; idempotency key per job run; retry with backoff |
| Web Crawler | Crawl URLs; respect robots.txt; dedup; store | Politeness (don't hammer one domain); dedup at scale | BFS queue (Kafka); Bloom filter for visited URLs; domain-based rate limiting; distributed workers |
| Ad Click Aggregator | Count clicks per ad per time window; query aggregates | Eventual accuracy is fine; very high event rate | Stream processing (Flink/Spark); Count-Min Sketch for hot keys; pre-aggregate per 1-min window |
| Payment System | Debit/credit accounts; ledger; idempotency | Exactly-once, no double-charge; strong consistency | Idempotency key + dedup table; double-entry ledger; Saga pattern for multi-step transactions |
| Metrics Monitoring | Collect metrics; aggregate; alert on threshold | High ingest throughput; efficient range queries | Time-series DB (InfluxDB/Prometheus); downsampling for long-term storage; alert engine with hysteresis |
| ChatGPT LLM API | Accept prompt; stream tokens back; multi-tenant | High GPU cost; streaming response; queue fairness | Request queue with priority tiers; GPU worker pool; Server-Sent Events (SSE) for streaming tokens |
Core Concepts File
→ See foundations.md for: CAP theorem, consistency models, caching patterns, database selection, numbers to know, and the full delivery framework.