Cheat Sheet
Quick reference for system design interviews. Everything you need at a glance.
·
| 1M req/day | ≈ 12 QPS |
| 1B req/day | ≈ 12,000 QPS |
| Seconds in a day | 86,400 (round to ~100K) |
| RAM access | 100 ns |
| SSD random read | 150 μs |
| HDD seek | 10 ms |
| Same-DC round trip | 500 μs |
| Cross-continent | 150 ms |
| 1 char | 1 byte (ASCII) / 2 bytes (Unicode) |
| 1M rows × 1KB | = 1 GB |
| 1B rows × 1KB | = 1 TB |
| 2^10 | ≈ 1 Thousand (1 KB) |
| 2^20 | ≈ 1 Million (1 MB) |
| 2^30 | ≈ 1 Billion (1 GB) |
| 2^40 | ≈ 1 Trillion (1 TB) |
| Step 1 (5 min) | Clarify requirements - ask questions, define scope, functional & non-functional requirements |
| Step 2 (5 min) | Back-of-envelope - calculate QPS, storage, bandwidth, peak traffic |
| Step 3 (10 min) | High-level design - draw core components, define APIs, data flow |
| Step 4 (15 min) | Deep dive - detail 2-3 interesting components, discuss algorithms |
| Step 5 (10 min) | Scaling & trade-offs - bottlenecks, failure handling, monitoring |
| SQL (PostgreSQL, MySQL) | Structured data, ACID, complex queries, joins, reporting. Good for: user accounts, orders, financial data |
| Document DB (MongoDB) | Flexible schema, JSON-like, good for: product catalogs, user profiles, content management |
| Key-Value (Redis, DynamoDB) | Simple get/put, highest throughput. Good for: caching, sessions, leaderboards, rate limiting |
| Wide-Column (Cassandra, HBase) | Write-optimized, massive scale. Good for: time-series, messaging, activity logs, IoT |
| Graph (Neo4j) | Relationship traversal. Good for: social networks, recommendation engines, fraud detection |
| Search (Elasticsearch) | Full-text search, inverted index. Good for: product search, log analysis, autocomplete |
| Time-Series (InfluxDB) | Optimized for time-stamped data. Good for: metrics, monitoring, IoT sensor data |
| Cache-Aside | App checks cache → miss → read DB → write cache. Most common. Good for: read-heavy workloads |
| Write-Through | Write to cache + DB simultaneously. Consistent but slower writes. Good for: data you always read after write |
| Write-Behind | Write to cache, async to DB. Fastest writes but risk of data loss. Good for: write-heavy, loss-tolerant |
| LRU Eviction | Remove least recently used. Best general-purpose policy. Default choice |
| TTL-based | Keys expire after time. Combine with LRU. Set based on data freshness needs |
| Round Robin | Equal distribution. Simple. Default choice |
| Weighted Round Robin | More traffic to stronger servers |
| Least Connections | Route to server with fewest active connections |
| IP Hash | Same client → same server. Session stickiness |
| Consistent Hashing | Minimize redistribution on server changes. Used by CDNs |
| Kafka | Distributed log, high throughput (millions/sec), ordered per partition, replay. Best for: event streaming, data pipelines |
| RabbitMQ | Traditional broker, flexible routing, lower latency. Best for: task queues, RPC, complex routing |
| SQS | AWS managed, simple, auto-scaling. Best for: serverless, simple async processing |
| Redis Streams | Lightweight, built into Redis. Best for: simple pub/sub when you already have Redis |
| CP Systems | MongoDB, HBase, Zookeeper - sacrifice availability during partitions. Use when: consistency is critical (financial) |
| AP Systems | Cassandra, DynamoDB, CouchDB - sacrifice consistency during partitions. Use when: availability is critical (social media) |
| Tunable | DynamoDB, Cassandra - choose per-request. W+R>N = strong consistency. W=1,R=1 = eventual consistency |
| Rate Limiting | Token Bucket (allows bursts), Sliding Window (precise), Fixed Window (simple). Use Redis + Lua for distributed |
| Idempotency | Same request → same result. Use unique idempotency keys. Critical for payments, message delivery |
| Circuit Breaker | Stop calling failing service. States: Closed → Open → Half-Open. Prevents cascading failures |
| CQRS | Separate read/write models. Write to normalized DB, read from denormalized view. Good for read-heavy systems |
| Saga Pattern | Distributed transactions via local transactions + compensating actions. Choreography (events) or Orchestration (coordinator) |
| Fan-out | On write: pre-compute (fast reads). On read: compute on demand (fast writes). Hybrid for celebrity problem |
| Consistent Hashing | Hash ring with virtual nodes. K/N keys move on node change. Used in: caches, DB sharding, CDNs |
| Bloom Filter | Probabilistic set membership. 'Definitely not' or 'probably yes'. 10 bits/element for 1% FP rate |
| 200 OK | Success |
| 201 Created | Resource created (POST) |
| 301 Moved Permanently | Permanent redirect (browser caches) |
| 302 Found | Temporary redirect (browser asks again) |
| 400 Bad Request | Invalid input |
| 401 Unauthorized | Not authenticated |
| 403 Forbidden | Authenticated but not authorized |
| 404 Not Found | Resource doesn't exist |
| 429 Too Many Requests | Rate limited |
| 500 Internal Server Error | Server bug |
| 503 Service Unavailable | Server overloaded or maintenance |
| Stateless servers | No session data on servers → easy horizontal scaling behind LB |
| Database read replicas | Offload reads to replicas, write to primary |
| Database sharding | Split data across DBs when single DB can't handle load |
| Caching layer | Redis/Memcached for hot data. 80/20 rule. Sub-ms latency |
| CDN | Edge cache for static assets and API responses. Reduce origin load |
| Message queues | Decouple services, absorb spikes, async processing |
| Connection pooling | Reuse DB/cache connections instead of creating new ones |
| Auto-scaling | Scale servers based on CPU/memory/queue depth metrics |