Dropbox: 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 + full-file upload
1. Current architecture
Where we are before growth pressure
3 apps + Postgres db.r6i.large + S3 bucket for files. Tables: `files(file_id, user_id, name, s3_key, size, checksum, updated_at)`. Upload: client PUTs entire file to S3 via presigned URL. Download: client GETs entire file. No dedup, no delta sync, no chunking.
2. Growth trigger
What changed — the traffic/data force
MVP launch. 100K users. ~1K uploads/hour, 10K download requests/sec. Average file 5MB. Users on desktop (fast internet). Total storage 100 TB growing 5 TB/month.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — S3 direct works at MVP scale
10K RPS = ~500 concurrent downloads × 100 Mbps average = 5 Gbps aggregate. S3 handles it. Full-file upload/download works because desktop bandwidth is stable + files are small (5MB avg). p99 upload 2-5s, download 1-3s.
S3 egress 5 Gbps, storage 100 TB growing 5 TB/mo, Postgres CPU 25%, upload success rate 98%
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Zero new infrastructure
- + S3 is essentially infinite storage
- + Simple architecture — no chunking, no dedup, no sync protocol
- + Team ships fast
- − Full-file upload wastes bandwidth (edit 1 byte → re-upload entire file)
- − S3 storage cost linear with total data (no dedup savings)
- − Sync UX poor for large files (1GB file = 15-60 second wait)
5. Chosen
The specific decision we're making
Do nothing — S3 direct is right at 10K RPS with 5MB average files
6. Trade-offs
What we're explicitly accepting to move forward
- Accept full-file re-upload wastes bandwidth (edit 1 byte → 5MB re-upload)
- Accept storage cost grows linearly with data
- Accept slow large-file sync UX
- Accept ceiling around 100K-500K users before economics forces change
7. New architecture
The system after this decision — headroom for the next 5-10x
3 apps + Postgres + S3. Client uploads full files via presigned URLs. Total cost: $3K/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 with millions of users + large files, S3 storage cost grows past $100K/mo. Also users complain: 'why does editing a 100MB doc re-upload the entire thing?'. Block-level dedup + delta sync — L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of Dropbox 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.