Skip to main content
Scale Evolution Timeline
6 rungs · 10K → 1B RPS

YouTube: 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.

Back to YouTube

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").

Rung 1 of 610K RPS
10K RPS

10K RPS — S3 + Postgres catalog + progressive download

1. Current architecture

Where we are before growth pressure

3 apps + Postgres catalog + S3 for videos. Users upload single-quality mp4. Playback: progressive HTTP download. Comments in Postgres. No transcoding, no CDN.

2. Growth trigger

What changed — the traffic/data force

Founding YouTube-like MVP. 100K DAU. ~1K uploads/day, 10K playback requests/sec. Users mostly on desktop. Average video 100 MB.

3. Bottleneck — what breaks FIRST?

The component that saturates as growth arrives

Bottleneck component

None yet — S3 progressive is fine at this scale

Why it breaks

10K playback requests/sec = ~500 concurrent streams × 2 Mbps = 1 Gbps aggregate. S3 handles it. Progressive download works on desktop. p99 first-byte: 800ms-2s.

Signal you'd see

S3 egress 1 Gbps, catalog Postgres CPU 25%, upload success rate 98%, playback stalls rare

4. Options — what could we do?

Alternatives an architect must consider before picking

Do nothing — S3 progressive works at MVP scale
CHOSEN
  • + Zero new infrastructure
  • + Simple architecture, fast to ship
  • + S3 is essentially infinite storage
  • Mobile UX poor (no ABR)
  • S3 egress cost trajectory bad ($0.09/GB)
  • Ceiling ~5-10K concurrent streams before pain
$500/mo

5. Chosen

The specific decision we're making

Do nothing — S3 progressive is right at 10K RPS

6. Trade-offs

What we're explicitly accepting to move forward

  • Accept desktop-only UX
  • Accept ceiling ~100K RPS on Postgres
  • Accept S3 first-byte latency (800ms-2s)

7. New architecture

The system after this decision — headroom for the next 5-10x

3 apps + Postgres + S3. Total cost: $500/mo.

Estimated: $500/mo

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 UGC upload volume, S3 egress + no ABR + no thumbnail generation cripples UX. Also creator studio (basic upload/publish flow) needs formal architecture. L5 shape.

What comes next in your Junior → Architect journey

You've traced 6 rungs of YouTube 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.