URL Shortener: 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 — single-box monolith
1. Current architecture
Where we are before growth pressure
One EC2 c6i.large + Postgres RDS db.t3.medium. Shortening writes to `urls(short_id PK, long_url, created_at)` with an auto-generated 7-char base62 short_id. Redirects do `SELECT long_url FROM urls WHERE short_id = ?` and issue a 302. Nothing else — no cache, no CDN, no queue.
2. Growth trigger
What changed — the traffic/data force
Startup ships internal marketing links. Peak 10K RPS spread evenly over 24h (avg ~1K RPS). ~85 M requests/day.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — headroom in every tier
Single box handles 10K RPS at <30ms p99 because 99% of traffic is reads (short_id → long_url lookup) which is a single indexed row fetch (~0.2ms per query). Postgres is at 20% CPU. App server is at 15% CPU. No queue latency, no cache invalidation problem.
app CPU 15%, DB CPU 20%, p99 latency 28ms, error rate 0.01%
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Cheapest possible
- + Zero operational complexity
- − No headroom for viral event or feature launch
5. Chosen
The specific decision we're making
Do nothing — 10K RPS is comfortably below capacity ceiling
6. Trade-offs
What we're explicitly accepting to move forward
- Accept single point of failure — one EC2 instance means any restart or crash = downtime
- Accept no read replicas — DB is single-writer + single-reader
- Accept no CDN — every redirect crosses the internet to origin
7. New architecture
The system after this decision — headroom for the next 5-10x
Same as current — no changes. Architecture is intentionally boring. Total cost: $130/mo.
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~50K RPS, single Postgres instance hits ~40% CPU and reads start queuing behind writes. That's the seed of the L5 problem.
What comes next in your Junior → Architect journey
You've traced 6 rungs of URL Shortener 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.