Netflix: Junior → Architect Evolution
The mandated interactive flow. Step through each rung, ask what breaks FIRST, weigh the options, and defend the chosen architecture. This is how architectural thinking is learned — not by reading a fixed design, but by tracing how it evolves under growth pressure.
Scale Evolution Timeline
Step through 6 architectural rungs, from 10K RPS to 1B RPS. At each rung, ask: what will break FIRST? Why? What options exist? Which one do we pick — and what are we accepting?
This is the reasoning cycle that separates a Junior developer ("here's an architecture") from an Architect ("here's why this architecture, why now, and what breaks next").
10K RPS — S3 direct + Postgres catalog + progressive download
1. Current architecture
Where we are before growth pressure
3 apps + Postgres db.r6i.large (catalog: `titles(title_id, name, description, s3_key)`) + S3 for video files (single mp4 per title). Client streams via progressive HTTP download from S3 URL. No transcoding, no CDN.
2. Growth trigger
What changed — the traffic/data force
MVP video platform. 10K catalog views/sec, ~500 concurrent video streams. Small library (~1000 titles). Users mostly on desktop with wired internet.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — S3 progressive download works
500 concurrent streams × 2 Mbps average = 1 Gbps aggregate egress from S3. S3 handles this trivially. Progressive download works because desktops have stable bandwidth. p99 first-byte: 500ms-2s (S3 first-byte latency).
S3 egress 1 Gbps, catalog Postgres CPU 25%, video load p99 3s (first frame), stream stalls rare
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Zero new infrastructure
- + S3 handles storage + delivery
- + Simple architecture — no transcoding, no CDN, no ABR player
- + Team ships fast
- − Buffering on slower networks — no adaptive bitrate
- − Mobile users on 3G/4G have poor experience
- − Single video quality — desktops overkill, mobiles underkill
5. Chosen
The specific decision we're making
Do nothing — S3 progressive download works at 10K RPS with desktop-first users
6. Trade-offs
What we're explicitly accepting to move forward
- Accept mobile UX limitations (no ABR)
- Accept single video quality per title
- Accept S3 first-byte latency (500ms-2s)
- Accept ceiling around 5-10K concurrent streams before egress cost becomes noticeable
7. New architecture
The system after this decision — headroom for the next 5-10x
3 apps → Postgres catalog + S3 video files. Progressive download to client. Total cost: $500/mo growing with S3 storage.
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~100K RPS with mobile users + growing library, S3 egress cost climbs. Also mobile users demand adaptive bitrate (ABR). Video quality (SD vs HD vs 4K) becomes a differentiator. HLS + CDN + transcoding — L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of Netflix evolution. Now try the same reasoning cycle on a system you don't know yet — pick from the Systems catalog and answer the same questions: current arch → growth trigger → bottleneck → options → chosen → trade-offs → new arch → next bottleneck. That is architecture.