Instagram: 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 metadata
1. Current architecture
Where we are before growth pressure
3 apps + Postgres db.r6i.large + S3 bucket for media. Upload: client uploads directly to S3 via presigned URL, app records metadata in Postgres (`media(media_id, user_id, s3_key, size, mime, created_at)`). Feed: `SELECT * FROM media WHERE user_id IN (followees) ORDER BY created_at DESC LIMIT 20`. Media served via S3 public URL.
2. Growth trigger
What changed — the traffic/data force
MVP. 100K DAU. ~2K photo uploads/hour, ~10K feed reads/sec. Average photo 1 MB, so ~200 GB/day storage growth. Users follow ~30 people on average.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — S3 + Postgres is right
S3 handles unlimited uploads at $0.023/GB/mo. Postgres handles feed queries fine at 10K RPS with proper indexing. Presigned URLs offload upload bandwidth from our servers. p99 upload: 500ms-2s (depends on user bandwidth). p99 feed: 15-30ms.
S3 storage growth 200 GB/day, Postgres CPU 30%, upload success rate 99%, feed p99 25ms
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Zero new infrastructure
- + S3 is essentially infinite storage at commodity price
- + Presigned URL uploads bypass our servers (no bandwidth cost on upload path)
- + Team already knows S3 + Postgres
- − Media served from S3 = 100-300ms first-byte latency globally
- − Every image loaded is a full-size download (no thumbnails yet)
- − Postgres feed query cost grows with follower graph
5. Chosen
The specific decision we're making
Do nothing — S3 + Postgres direct is the right architecture at 10K RPS
6. Trade-offs
What we're explicitly accepting to move forward
- Accept 100-300ms first-byte latency for media (S3 direct)
- Accept full-size image downloads (no thumbnails) — mobile users on 3G suffer
- Accept ceiling around 50-100K RPS on Postgres for feed queries
- Accept S3 storage costs growing linearly — $0.023/GB/mo × 200 GB/day = $70/mo growing to ~$1K/mo after year 1
7. New architecture
The system after this decision — headroom for the next 5-10x
3 apps → Postgres (metadata) + S3 (media). Client uploads directly to S3 via presigned URL. Feed served from Postgres. Media served from S3 URLs. Total cost: $400/mo growing with S3.
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~100K RPS, media delivery latency (S3 first-byte 100-300ms) kills UX. Also transcoding for mobile (thumbnails, WebP, video H.264) becomes mandatory — sending 5MB photo to mobile users is wasteful. CDN + transcoding pipeline — L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of Instagram 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.