🏗️
System Design
Estimation numbers, caching, CAP, and the building-block one-liners.
Numbers to know
| Seconds/day | 86,400 ≈ 10⁵ |
|---|---|
| 1 million writes/day | ≈ 12 writes/sec |
| Read:write ratio (typical) | ~100:1 for social/feeds |
| SSD read | ~100 µs · Memory read ~100 ns · Network RTT (same DC) ~0.5 ms |
| Char ≈ 1 byte | 1 KB ≈ short post · 1 MB ≈ small image |
Caching strategies
Cache stampede fix: lock/single-flight on miss, or stagger TTLs.
| Strategy | How | Trade-off |
|---|---|---|
| Cache-aside | App reads cache, on miss loads DB & fills cache | Most common; stale risk → use TTL |
| Write-through | Write to cache + DB synchronously | Consistent, slower writes |
| Write-back | Write cache, flush to DB later | Fast writes, data-loss risk |
CAP & consistency
- CAP: under a network partition you pick Consistency OR Availability.
- CP (HBase, Zookeeper) — reject some requests to stay consistent.
- AP (Cassandra, DynamoDB) — always answer, may serve stale data.
- Models: strong > read-your-writes > monotonic > eventual.
SQL vs NoSQL
| SQL | NoSQL | |
|---|---|---|
| Schema | Fixed, relational | Flexible / denormalized |
| Scale | Vertical (+ read replicas, sharding) | Horizontal by design |
| Best for | Transactions, joins, integrity | High write throughput, simple access by key |
Building blocks (one-liners)
- Load balancer: spread traffic across stateless instances (L4 = transport, L7 = HTTP-aware).
- CDN: cache static assets near users; pull (lazy) vs push.
- Queue (Kafka/SQS): decouple producers/consumers, absorb spikes, async work.
- Sharding: partition data by key (consistent hashing avoids mass re-shuffle).
- Replication: copies for read scale + failover (leader-follower).
SDE-2 Launchpad · System Design cheat sheet