← Back to System DesignSystem Design Interview Cheat Sheet
Quick Reference for 2026
This is your one-page reference for system design interviews. It covers the 8 core building blocks you will encounter in almost every design question. For each concept, you will find when to reach for it, when to avoid it, and the key tradeoff interviewers expect you to articulate.
Load Balancing
Distributes traffic across servers.
When to use- High-traffic services
- Stateless APIs
When NOT to use- Single-server apps
- WebSocket-heavy services without sticky sessions
Key tradeoff: Round-robin is simple but ignores server health; least-connections adapts but adds monitoring overhead.
Caching
Stores frequently accessed data closer to the consumer.
When to use- Read-heavy workloads
- Expensive computations
When NOT to use- Write-heavy data
- Data requiring real-time consistency
Key tradeoff: Cache invalidation is the hardest problem — stale data vs cache miss penalties.
Database Sharding
Splits data horizontally across multiple databases.
When to use- Dataset exceeds single-machine capacity
- Need write scalability
When NOT to use- Dataset fits in memory
- Complex cross-entity queries required
Key tradeoff: Write scalability vs cross-shard query complexity and operational overhead.
Replication
Copies data across multiple nodes.
When to use- Read scalability and fault tolerance
- Geographic distribution
When NOT to use- Write-heavy workloads with strong consistency requirements
Key tradeoff: Synchronous replication = strong consistency but higher latency. Async = fast but eventual consistency.
Message Queues
Decouples producers from consumers with async processing.
When to use- Spiky workloads and cross-service communication
- Event-driven architectures
When NOT to use- Low-latency synchronous operations
- Simple request-response flows
Key tradeoff: Decoupling and resilience vs added latency, complexity, and message ordering challenges.
CDN (Content Delivery Network)
Serves static content from edge locations near users.
When to use- Global user base and static assets
- Media-heavy applications
When NOT to use- Dynamic personalized content
- Internal tools
Key tradeoff: Reduced latency and origin load vs cache invalidation complexity and cost.
Rate Limiting
Constrains the number of requests a client can make.
When to use- Public APIs and preventing abuse
- Protecting downstream services
When NOT to use- Internal trusted services
- Batch processing pipelines
Key tradeoff: Protection from abuse vs potential impact on legitimate users during traffic spikes.
Consistent Hashing
Distributes keys across nodes minimizing redistribution when nodes change.
When to use- Distributed caches and sharded databases
- Load balancing across dynamic server pools
When NOT to use- Static clusters
- Small fixed-size deployments
Key tradeoff: Minimal rebalancing on node changes vs added complexity and potential for uneven distribution without virtual nodes.
How to Use This in Your Interview
- Start with requirements — identify which 3-4 of these components your design needs. Not every system uses all eight.
- For each component, state the tradeoff— interviewers test reasoning, not memorization. Saying "I would use caching here because the workload is read-heavy, but we need to handle invalidation via TTL" beats listing features.
- Dive deeper into CAP Theorem and Database Sharding for the most commonly tested sub-topics.
Test Your System Design Knowledge
Reading concepts is step one. Practice applying them to real interview scenarios — from designing a URL shortener to architecting a chat system.
System Design Interview Guide