System Design Interview Cheat Sheets
HLD & LLD HubComprehensive architectural blueprints, scalability patterns, CAP tradeoffs, and production failure-mode handling.
0% core modules covered
System design is not about finding the single "perfect" tool. It is about understanding trade-offs, calculating constraints, and anticipating failure points.
Review Operating Systems, DBMS & SQL, and Computer Networks fundamentals.
Load Balancing & Reverse Proxies
Distributing incoming network traffic across multiple servers (Layer 4 TCP vs Layer 7 HTTP) to prevent bottlenecks and ensure high availability.
Key Architectural Concepts
- Algorithms: Round Robin, Weighted Round Robin, Least Connections, IP Hash
- Layer 4 (Transport, high throughput) vs Layer 7 (Application, path-based routing, SSL termination)
- Health checking & active failover between server pools
- Popular tools: Nginx, HAProxy, AWS ALB/NLB, Envoy
Layer 7 allows smart routing and caching but requires more CPU power for SSL termination and header parsing compared to raw Layer 4 forwarding.
Always mention health checks and session stickiness risks (sticky sessions can cause unequal load distribution).
Caching Strategies & Invalidation
Storing frequently accessed data in RAM (Redis, Memcached) to drastically cut database read load and latency.
Key Architectural Concepts
- Patterns: Cache-Aside (Lazy loading), Write-Through, Write-Behind (Write-Back), Refresh-Ahead
- Eviction Policies: LRU (Least Recently Used), LFU (Least Frequently Used), FIFO
- Cache Invalidation Pitfalls: Cache Penetration, Cache Stampede (Thundering Herd), Cache Avalanche
- TTL (Time-To-Live) and proactive warming
Write-Back offers ultra-fast writes but risks data loss if the cache server crashes before flushing to the primary database.
Explain how to defend against Cache Stampede using distributed mutex locks or stale-while-revalidate patterns.
Database Sharding & Replication
Partitioning large datasets horizontally across multiple database nodes (Sharding) combined with Primary-Replica replication for read scaling.
Key Architectural Concepts
- Primary-Replica (Master-Slave): Writes go to Primary; Reads distributed across Replicas
- Horizontal Sharding strategies: Range-based, Hash-based (Consistent Hashing), Directory-based
- Replication lag and eventual consistency vs synchronous replication latency
- Cross-shard joins and distributed transactions (2-Phase Commit)
Sharding enables infinite horizontal scaling but complicates schema migrations, cross-shard queries, and transactional rollbacks.
Use Consistent Hashing to minimize data redistribution when adding or removing database shard nodes.
Message Queues & Event-Driven Architecture
Decoupling producers and consumers through durable, asynchronous message brokers (Kafka, RabbitMQ, SQS, BullMQ).
Key Architectural Concepts
- Point-to-Point (Queue) vs Publish-Subscribe (Topics)
- At-most-once, At-least-once, and Exactly-once delivery semantics
- Backpressure handling, rate leveling, and dead-letter queues (DLQ)
- Idempotency: Ensuring duplicate messages do not produce corrupted side effects
Asynchronous event architecture makes systems resilient to traffic spikes but introduces eventual consistency and complex tracing/debugging.
Always explain how consumers achieve idempotency (e.g., using unique transaction IDs with database unique constraints).
Rate Limiting & API Gateway
Preventing abuse, DoS attacks, and API quota exhaustion using algorithmic traffic throttling at the network perimeter.
Key Architectural Concepts
- Algorithms: Token Bucket, Leaky Bucket, Fixed Window Counter, Sliding Window Log, Sliding Window Counter
- Distributed rate limiting using Redis atomic INCR and Lua scripts
- HTTP 429 Too Many Requests response headers (Retry-After, X-RateLimit-Remaining)
Sliding Window Log is 100% accurate but memory-intensive; Token Bucket is memory-efficient and allows controlled bursts.
Token Bucket is the industry standard (used by AWS, Stripe, Cloudflare) because it naturally accommodates bursts while maintaining average throughput.
CAP Theorem & PACELC Trade-Offs
Understanding the fundamental physics of distributed data systems: Consistency, Availability, and Partition Tolerance.
Key Architectural Concepts
- CAP Theorem: In the presence of a network Partition (P), you must choose between Consistency (C) or Availability (A)
- CP Systems: Bigtable, HBase, MongoDB (majority write), Redis Cluster (default)
- AP Systems: Cassandra, DynamoDB (eventual consistency), CouchDB
- PACELC Extension: Even when there is no partition (E), trade off Latency (L) versus Consistency (C)
Strict consistency guarantees data correctness across all nodes but increases read/write latency and rejects requests during partitions.
State clearly that network partitions are unavoidable in real-world distributed networks, so the real choice is CP vs AP during a split.