System Design Interview Cheat Sheet

System design interviews test breadth as much as depth. Interviewers want to see that you can reason about tradeoffs across networking, storage, compute, and reliability — often in under 45 minutes. Having a mental checklist of building blocks prevents you from forgetting critical components under pressure.

This cheat sheet is not a substitute for deep understanding. Use it as a quick-reference during your final review, or as a skeleton to build your own notes around.

1. Clarify requirements

Separate functional requirements (what the system does) from non-functional requirements (latency, availability, consistency, throughput). Ask who the users are, what the expected scale is, and whether the system is read-heavy or write-heavy.

2. Back-of-envelope estimation

Estimate daily active users, requests per second, storage needs, and bandwidth. Use round numbers. The goal is to determine whether you need one server or thousands, not to be precise. Common reference: 1 million seconds is about 11.5 days.

3. High-level design

Draw the core components: clients, load balancers, application servers, databases, caches, and any external services. Show the data flow from request to response. Keep it simple first, then add complexity as you drill into specific areas.

4. Deep dive

The interviewer will pick one or two areas to explore. Be ready to discuss data models, API contracts, failure scenarios, and scaling strategies for each component.

Load balancers

Distribute traffic across servers. Layer 4 (TCP) is faster but less flexible. Layer 7 (HTTP) can route based on URL, headers, or cookies. Algorithms include round-robin, least connections, and consistent hashing. Health checks remove unhealthy servers from the pool automatically.

Caching

Reduces latency and database load. Cache-aside (application checks cache first, then DB) is the most common pattern. Write-through updates cache and DB together. Write-behind queues DB writes asynchronously. Use Redis or Memcached for distributed caching. Set TTLs to prevent stale data, and consider cache invalidation carefully — it is one of the two hard problems in computer science.

Databases

Relational databases (PostgreSQL, MySQL) provide ACID transactions and are best for structured data with complex queries. NoSQL databases (MongoDB, Cassandra, DynamoDB) offer flexible schemas and horizontal scaling. Choose based on your data model and access patterns, not on hype.

Message queues

Decouple producers from consumers. Kafka is ideal for high-throughput event streaming with ordered delivery. RabbitMQ and SQS work well for task queues. Message queues enable asynchronous processing, retry logic, and backpressure handling.

CDNs

Content delivery networks cache static assets at edge locations close to users. This reduces latency for images, CSS, JavaScript, and video. Use pull-based CDNs for most cases; push-based when you control exactly what gets cached.

Horizontal vs. vertical scaling

Vertical scaling (bigger machine) is simpler but has a ceiling. Horizontal scaling (more machines) requires distributed coordination but scales further. Most real systems combine both: scale vertically until it is impractical, then scale horizontally.

Database sharding

Split data across multiple database instances by a shard key (user ID, geography, etc.). Range-based sharding can create hotspots. Hash-based sharding distributes evenly but makes range queries harder. Consistent hashing minimizes data movement when adding or removing shards.

Replication

Leader-follower replication provides read scaling and failover. Multi-leader replication enables multi-region writes but introduces conflict resolution complexity. Quorum-based replication (used by Cassandra and DynamoDB) offers tunable consistency.

CAP theorem

In the presence of a network partition, you must choose between consistency and availability. In practice, partitions are rare but real. Most systems choose availability and accept eventual consistency. Know where your design falls on this spectrum and why.

Rate limiting

Protect services from abuse and cascading failures. Token bucket and sliding window are the most common algorithms. Apply at the API gateway level for simplicity.

Circuit breakers

When a downstream service fails repeatedly, stop sending requests for a cooldown period. This prevents cascade failures and gives the failing service time to recover. Libraries like Hystrix or Resilience4j implement this pattern.

URL shortener: hash function for short codes, base62 encoding, 301 vs 302 redirects, analytics via async logging. Chat system: WebSocket connections, presence service, message ordering via sequence numbers, fan-out on write vs fan-out on read. News feed: push model for users with few followers, pull model for celebrities, hybrid for most systems. Rate limiter: token bucket per user, Redis for distributed counting, return 429 with Retry-After header.

When working through these problems live, tools like Phantom Coder can help you recall key components and patterns so you can focus on articulating your reasoning clearly.

Memory: L1 cache reference 0.5 ns, main memory reference 100 ns. Storage: SSD random read 16 microseconds, HDD seek 4 ms. Network: round trip within a data center 0.5 ms, cross-continent 150 ms. Throughput: a single server can handle roughly 10K-50K concurrent connections, a single PostgreSQL instance can handle thousands of queries per second.

Keep these orders of magnitude in mind during estimation. You do not need exact numbers — knowing that disk is 100x slower than memory and network adds milliseconds is enough.