System Design Cheat Sheet — 12 Templates That Ship (2026)
There are ~12 system-design prompts that account for 90% of what Google, Meta, Amazon, and Stripe actually ask. Every prompt follows the same 5-block structure: functional requirements → capacity estimate → API sketch → data model → scaling strategy. This cheat sheet gives you a compact walkthrough for all 12 — memorize the shape, adapt the details to the specific prompt on the day.
Practice these live, in your voice
MiPrep's practice mode turns your resume into a rehearsed answer set. Talk through the idioms the way top-tier interviewers score.
Download MiPrep 🔒 Interview audio is never stored on our serversAdvanced questions
1. Design a URL shortener (bit.ly). Advanced
Requirements: shorten a URL, resolve short → long, ~100M new URLs/day, read:write = 100:1, 10ms p99 read. Capacity: 100M writes/day = ~1200 QPS write, ~120K QPS read. API: POST /shorten (long_url) → short_code; GET /:code → 301. Data model: (short_code PK, long_url, created_at, expires_at). Scaling: base62-encode a distributed counter (Snowflake or DB sequence), cache hot codes in Redis (LRU, 1M entries), Postgres for source of truth with read replicas, CDN in front for the redirect if the mapping is static.
2. Design a news feed (Facebook / Twitter). Advanced
Requirements: 500M DAU, follow N users, feed of recent posts, <200ms load. Capacity: 500M users × 10 feed loads/day = 5B reads/day = ~60K QPS. API: GET /feed?user_id&cursor → posts[]. Data model: posts(id, author_id, content, ts), follows(follower, followee). Scaling strategy: hybrid push+pull. Push: on-write, fan-out to followers' feed caches (Redis list per user, capped 500). Pull: for celebrity users (>10K followers), skip fan-out and pull at read time to avoid write amplification. Rank in a separate ML service, cache top 20.
3. Design a chat app (WhatsApp / Slack). Advanced
Requirements: 1-to-1 + group chat (up to 1000), delivery <500ms, read receipts, offline delivery. Capacity: 1B users × 40 msgs/day = 40B msgs/day = ~500K QPS. API: WebSocket persistent conn; send(chat_id, msg), receive push. Data model: messages(id, chat_id, sender, content, ts), chats(id, participants[]). Scaling: sticky WebSocket connections via consistent hashing to a chat-server fleet, Kafka for durable message log per chat, Cassandra for message history (time-series partitioning by chat_id + month), separate presence service, APNs/FCM for offline push.
4. Design a ride-share service (Uber). Advanced
Requirements: match rider to nearest driver, real-time location, surge pricing, ETA. Capacity: 10M active users, 1M active drivers, ~5 location updates/sec per driver = 5M QPS location writes. API: rider POST /ride (pickup, dropoff) → driver_id + ETA; driver PUT /location. Data model: drivers(id, lat, lng, status), rides(id, rider, driver, status, timeline[]). Scaling: geospatial index — QuadTree or S2 cell IDs, sharded by geo region; matching service reads only nearby cells (O(cells) not O(drivers)); Redis for hot driver locations with 5s TTL; Kafka for the driver-location firehose; separate pricing service reading from real-time supply/demand.
5. Design a video streaming service (YouTube / Netflix). Advanced
Requirements: upload video, transcode to multiple qualities, stream globally with adaptive bitrate. Capacity: 500 hours uploaded/min, 2B daily viewers, petabytes of data. API: POST /upload → upload_url (S3 multipart); GET /video/:id/manifest → HLS m3u8. Data model: videos(id, uploader, status, duration, metadata), manifests(video_id, quality, cdn_url). Scaling: upload direct to S3, async transcoding job queue (SQS + workers) produces 240p/480p/720p/1080p HLS segments, CDN (CloudFront/Akamai) serves segments from edge, ABR client picks quality based on bandwidth, separate recommendation service.
6. Design an ecommerce cart + checkout (Amazon). Advanced
Requirements: add to cart, persist across sessions, checkout with atomicity (don't oversell), payment integration. Capacity: 300M users, 10% carts at any time = 30M active carts, 1M checkouts/day peak. API: POST /cart/items, POST /checkout → order_id. Data model: carts(user_id, items[]), inventory(sku, available), orders(id, user, items, status). Scaling: cart in Redis (session-affinity), inventory in Postgres with row-level locking on decrement OR event-sourced (Kafka) with compensation on failure, payment via Stripe idempotency keys, saga pattern for multi-step checkout (reserve inventory → charge → fulfill → confirm or compensate).
7. Design a rate limiter. Advanced
Requirements: limit N requests per user per window, distributed across API fleet, low overhead (<5ms). Capacity: 100K API QPS, 10M unique users. API: middleware — allow(user_id) → bool. Data model: counter per (user_id, window). Scaling: sliding-window log (Redis sorted set of timestamps) is accurate but memory-heavy; token bucket in Redis with atomic Lua script is the standard — INCR + EXPIRE in a single round-trip; per-node local counter with periodic sync for very high QPS (accept slight over-limit). Return 429 with Retry-After header.
8. Design a distributed cache (Redis / Memcached). Advanced
Requirements: sub-ms get/set, terabytes total, survive node failures. Capacity: 10TB working set, 1M QPS. API: GET/SET/DEL/EXPIRE. Data model: key → value with TTL. Scaling: consistent hashing across N nodes (virtual nodes for balance), replication factor 2 (primary + replica async), client-side hashing for zero-hop lookup, TTL-based eviction + LRU when memory pressure, gossip protocol for membership. Handle hot keys with per-key request coalescing on the client.
9. Design a web crawler (Googlebot). Advanced
Requirements: crawl 10B URLs, respect robots.txt, dedup, handle politeness (max QPS per domain). Capacity: 10B URLs / 30 days = ~4K URLs/sec. API: internal — no external API. Data model: url_frontier (priority queue), seen_urls (Bloom filter → HBase), content_store (S3 by URL hash). Scaling: distributed URL frontier partitioned by domain hash (all URLs for a domain go to one worker → politeness enforced locally), Bloom filter for O(1) dup check (accept 0.1% false positives), fetch → parse → extract links → enqueue new URLs, robots.txt cache per domain.
10. Design a payment system (Stripe). Advanced
Requirements: charge card, idempotency (retries don't double-charge), settlement, webhooks. Capacity: 100M merchants, 10K charges/sec peak. API: POST /charges with Idempotency-Key header → charge_id. Data model: charges(id, merchant, amount, status, idempotency_key UNIQUE), events (append-only ledger). Scaling: idempotency via unique-key on (merchant_id, idempotency_key) → return stored response on retry; double-entry ledger in Postgres (never delete/update, only append); async webhook delivery via SQS with exponential backoff; sharded by merchant_id; separate reconciliation service comparing internal ledger vs card-network reports.
11. Design a notification service (push, email, SMS). Advanced
Requirements: send notifications across channels, dedupe, respect user preferences, batch when possible. Capacity: 1B users, 10 notifs/day = 10B/day = ~120K QPS. API: POST /notify (user_id, template, data). Data model: templates, preferences(user_id, channel, opt_in), delivery_log(id, user, status). Scaling: single ingest queue (Kafka) → routing service reads user prefs → per-channel worker fleets (APNs, FCM, SES, Twilio), rate-limit per user (max 3 pushes/hour), dedup key (user_id + template + entity_id) with 24h Redis TTL, dead-letter queue for failed deliveries.
12. Design a search autocomplete (Google search bar). Advanced
Requirements: prefix suggestions ranked by popularity, <100ms latency, updates hourly. Capacity: 5B searches/day → suggestions on every keystroke = ~500K QPS. API: GET /suggest?prefix=xyz → top-10 completions. Data model: trie of prefixes with top-K suggestions cached at each node. Scaling: precompute top-10 completions per prefix offline (MapReduce over query logs), store trie in memory sharded by prefix hash across a suggestion-service fleet, edge cache for hottest prefixes, personalization layer (small re-rank based on user history), refresh trie every hour from batched logs.
Common mistakes candidates make
- Jumping to the architecture diagram before nailing functional + non-functional requirements — interviewer marks you as unfocused.
- Skipping capacity estimation — even wrong numbers are better than none; they show you're thinking about scale.
- Designing for 1B users when the interviewer said 1M — over-engineering signals inability to right-size solutions.
- Forgetting the failure story — every design should have 'what happens when X dies?' answered for the DB, cache, and workers.
- Ignoring data consistency tradeoffs — say 'eventual consistency here, strong here, because...' or the interviewer will probe.
Study strategy
Three-week plan. Week 1: memorize the 5-block template (requirements → capacity → API → data → scaling) and do all 12 templates above cold — one per day, 30 minutes each. Week 2: 2 mock system-design interviews per week with a peer; force yourself to explain aloud without writing. Week 3: read one real engineering blog post per day (Uber, Stripe, Meta, Netflix) and map it to the 5-block template — this builds the vocabulary that separates senior from junior candidates.
Do timed mocks with MiPrep before the real thing
Upload your resume and target job description. MiPrep generates a rehearsed answer set in your voice from your own projects — so mock interviews sound like real ones.
Get MiPrep — free 🔒 Interview audio is never stored on our servers