# System Design Quick Reference

## Interview Framework

1. **Requirements** — Functional + non-functional (scale, latency, availability)
2. **Estimation** — DAU, QPS, storage (back-of-envelope)
3. **High-level design** — Boxes and arrows, API, data flow
4. **Deep dive** — 2–3 components in detail
5. **Bottlenecks** — SPOFs, scale limits, mitigations

## CAP Theorem

- **C**onsistency, **A**vailability, **P**artition tolerance — pick two
- In practice: **CP** (banking) or **AP** (social feeds)

## Caching

| Strategy | When |
|----------|------|
| Cache-aside | App manages cache; on miss → DB → populate |
| Write-through | Write to cache + DB together |
| CDN | Static assets, edge |
| Redis/Memcached | App-layer hot data |

## Database

| Type | Use case |
|------|----------|
| SQL | ACID, joins, relational |
| NoSQL document | Flexible schema, high write |
| NoSQL key-value | Simple lookups |
| Sharding | Partition by key (user_id, etc.) |
| Replication | Read replicas for scale |

## Load Balancing

- Round-robin, least connections, consistent hashing
- Health checks to remove unhealthy nodes

## Message Queues

- Decouple producers/consumers
- Async processing, buffering, retries
- Kafka, RabbitMQ, SQS

## Rate Limiting

- Token bucket, sliding window, fixed window
- `429 Too Many Requests`, `Retry-After` header

## Microservices vs Monolith

- Start monolith; extract when boundaries clear
- Per-service DB, independent deploy

## Consistent Hashing

- Ring of hash space; nodes own ranges
- Add/remove node → minimal key movement