# System Design

> Design scalable, reliable systems from requirements.

## When to Use
- System design interviews
- New service/product architecture
- "Design a system that does X"

## Design Process
1. **Clarify requirements** — functional (what it does) + non-functional (scale, latency, availability)
2. **Estimate scale** — users, requests/sec, data volume, growth rate
3. **Define the API** — what endpoints/interfaces does the system expose?
4. **Design the data model** — what's stored, how it's structured, how it's queried
5. **High-level architecture** — draw the boxes and arrows (client → LB → API → DB)
6. **Deep dive on critical path** — the hardest part of the system, in detail
7. **Address bottlenecks** — caching, partitioning, replication, async processing
8. **Discuss tradeoffs** — every decision has a cost, name it

## Non-Functional Requirements Checklist
- [ ] Expected QPS (queries per second)
- [ ] Latency requirements (p50, p99)
- [ ] Availability target (99.9%? 99.99%?)
- [ ] Data durability requirements
- [ ] Consistency model (strong? eventual?)
- [ ] Security requirements
- [ ] Cost constraints

## Common Patterns
- **Read-heavy:** cache layer (Redis), CDN, read replicas
- **Write-heavy:** write-ahead log, async processing, event queue
- **Search:** inverted index (Elasticsearch), FTS5 for smaller scale
- **Real-time:** WebSocket, SSE, pub/sub (Redis, Kafka)
- **Batch processing:** job queue, scheduled workers, MapReduce

## Design Document Template
```
## System: [Name]
### Requirements
[Functional + non-functional]

### Scale Estimates
[Users, QPS, storage, bandwidth]

### Architecture Diagram
[ASCII or link to diagram]

### Data Model
[Schema + access patterns]

### Critical Path Deep Dive
[The hardest technical challenge, in detail]

### Tradeoffs
| Decision | Chosen | Alternative | Why |
|----------|--------|------------|-----|
```
