System Design Fundamentals
Core Building Blocks
Every large-scale system is built from the same fundamental components. Knowing these building blocks and when to use each one is essential for system design interviews.
Load Balancers
Distribute traffic across multiple servers to prevent any single server from becoming a bottleneck.
| Type | Layer | How It Works | Use Case |
|---|---|---|---|
| L4 (Transport) | TCP/UDP | Routes by IP and port | High throughput, simple routing |
| L7 (Application) | HTTP | Routes by URL, headers, cookies | Content-based routing, SSL termination |
Algorithms: Round Robin, Least Connections, IP Hash, Weighted Round Robin
Caching
Store frequently accessed data in fast storage (memory) to reduce database load and latency.
Caching Strategies:
| Strategy | How It Works | Best For |
|---|---|---|
| Cache-Aside | App checks cache first, loads from DB on miss | General purpose, read-heavy |
| Write-Through | Write to cache and DB simultaneously | Data consistency |
| Write-Back | Write to cache, async write to DB | Write-heavy, risk of data loss |
| Read-Through | Cache loads from DB transparently | Simplicity |
Cache-Aside Pattern:
1. App checks Redis → Hit? Return data
2. Miss? Query database
3. Store result in Redis with TTL
4. Return data to client
Popular Caches: Redis (most common in interviews), Memcached
Interview Tip: Always mention cache invalidation as a challenge. It's one of the hardest problems in distributed systems.
Databases
SQL vs NoSQL
| Feature | SQL (PostgreSQL, MySQL) | NoSQL (MongoDB, DynamoDB) |
|---|---|---|
| Schema | Fixed, structured | Flexible, schema-less |
| Scaling | Vertical (scale up) | Horizontal (scale out) |
| Joins | Native support | Limited or manual |
| Transactions | ACID compliant | Eventual consistency (usually) |
| Best for | Complex queries, relationships | High throughput, flexible data |
Scaling Databases
Replication: Copy data to multiple servers
- Master-slave: one writer, many readers
- Master-master: multiple writers (complex conflict resolution)
Sharding: Split data across multiple databases
- Range-based: user IDs 1-1M on shard 1, 1M-2M on shard 2
- Hash-based: hash(user_id) % num_shards
- Consistent hashing: minimizes redistribution when adding/removing shards
Message Queues
Decouple services by communicating through a queue instead of direct calls.
| System | Strengths | Use Case |
|---|---|---|
| Kafka | High throughput, log-based, replay | Event streaming, logs |
| RabbitMQ | Flexible routing, acknowledgments | Task queues, RPC |
| SQS | Managed, simple, reliable | AWS-native workflows |
When to Use: Asynchronous processing, peak load handling, service decoupling, event-driven architecture.
CDN (Content Delivery Network)
Serve static content (images, CSS, JS) from servers geographically close to users.
- Push CDN: You upload content to CDN (good for static sites)
- Pull CDN: CDN fetches from origin on first request, then caches (good for dynamic content)
API Design
| Style | Format | Best For |
|---|---|---|
| REST | HTTP + JSON | General CRUD, simple APIs |
| GraphQL | Single endpoint, query language | Complex data needs, mobile apps |
| gRPC | Protocol Buffers, HTTP/2 | Microservice communication, low latency |
Building Blocks Cheat Sheet
| Need | Solution |
|---|---|
| Distribute traffic | Load Balancer |
| Reduce latency | Cache (Redis) |
| Store structured data | SQL Database |
| Store unstructured data | NoSQL Database |
| Async processing | Message Queue |
| Serve static content globally | CDN |
| Search text | Elasticsearch |
| Unique IDs at scale | Snowflake ID / UUID |
Next, let's apply these building blocks to classic system design problems. :::