The System Design Framework

Every system design interview follows a pattern: (1) Requirements clarification — 5 minutes, (2) High-level design — 10 minutes, (3) Deep dive into components — 15 minutes, (4) Bottlenecks and tradeoffs — 10 minutes. Never jump straight to architecture. Ask about expected users, read/write ratio, latency requirements, and data size. These constraints shape every decision.

For example, designing a URL shortener for 100 users is fundamentally different from one handling 1 billion URLs. The interviewer wants to see how you think about scale, not just draw boxes and arrows.

Core Building Blocks

Load Balancers: Distribute traffic across servers. Round-robin for simple cases, weighted for heterogeneous servers, consistent hashing for stateful services. CDN: Cache static content at edge locations. Reduces latency for global users. Reverse Proxy: SSL termination, compression, rate limiting. Nginx and HAProxy are common choices. API Gateway: Authentication, rate limiting, request routing for microservices. Every modern system needs these components — know when and why to use each.

Database Design

SQL vs NoSQL: Use SQL for ACID transactions, complex queries, and relationships. Use NoSQL for flexible schemas, horizontal scaling, and high write throughput. Sharding: Split data across database instances. Hash-based sharding for even distribution, range-based for time-series data. Replication: Master-slave for read scaling, multi-master for write availability. Understand CAP theorem: you can't have consistency, availability, and partition tolerance simultaneously. Choose CP for banking, AP for social feeds. See our SQL vs NoSQL comparison for deeper analysis.

Caching Strategies

Where to cache: Client-side (browser), CDN, application-level (Redis/Memcached), database query cache. Patterns: Cache-aside (read-through), write-through, write-behind. Eviction: LRU (most common), LFU, TTL-based. Cache invalidation: The hardest problem in CS after naming things. Use TTL for simplicity, event-driven invalidation for consistency. Redis handles 100K+ operations/second — it solves most caching needs. Learn more in our Redis caching guide.

Message Queues & Event Systems

When to use: Decoupling services, handling traffic spikes, async processing. Kafka: High-throughput, ordered, persistent event streaming. Use for event sourcing, log aggregation, real-time analytics. RabbitMQ: Traditional message broker with routing, dead-letter queues. Use for task queues and request-response patterns. SQS: Managed queue with at-least-once delivery. Simplest option for AWS-native architectures. Message queues turn synchronous bottlenecks into async pipelines.

Practice Problems

URL Shortener: Base62 encoding, counter-based ID generation, Redis cache for hot URLs. Twitter/News Feed: Fan-out on write vs fan-out on read, timeline caching, celebrity problem. Chat System: WebSocket connections, message storage, online presence. Rate Limiter: Token bucket, sliding window, distributed rate limiting with Redis. Search Autocomplete: Trie data structure, prefix matching, ranking by frequency. Practice each of these designs multiple times until you can present them fluently in 35 minutes.

Back-of-Envelope Estimation

Know these numbers: 1 day = 86,400 seconds ≈ 100K. 1 million requests/day ≈ 12 requests/second. 1 byte of text, 10KB for a web page, 1MB for an image, 1GB = 1 billion bytes. Network: 1 Gbps bandwidth. SSD: 100K IOPS random read. Memory: 100ns access time. These estimates help you quickly size databases, calculate storage needs, and determine if a single server can handle the load.

Senior-Level Topics

Consensus: Raft, Paxos for distributed agreement. Consistent Hashing: For distributed caches and databases. Event Sourcing: Store events instead of state. CQRS: Separate read and write models. Circuit Breaker: Prevent cascade failures. These topics distinguish senior engineers from mid-level. You don't need to implement them, but you should know when to apply them and their tradeoffs.