Design a File Storage Service
People store files online, open them from any device, and edit them together. Downloads are most of the traffic, uploads are rarer but heavy, and two people saving the same file at once must not overwrite each other. Other devices are told when a file changes, and uploaded images get preview thumbnails made in the background.
Constraints
- Opening or downloading a file must start within 200 ms
- About 10,000 file requests per second at peak, and about 1 in 12 is an upload
- Two people saving the same file at once must never silently overwrite each other
- Other devices learn about a change within a second, but the service works without that
- Thumbnails are generated in the background after an upload
- Keep infrastructure under $8,000 a month
Scenarios to survive
Typical peak
Steady downloads with the usual share of uploads.
Interviewer asks: Downloads and uploads stress different things. How do you keep a big upload from slowing everyone's downloads?
Monday morning (3x)
Everyone opens their files at once and traffic triples.
Interviewer asks: Most of the extra load is downloads of popular files. What absorbs it before it reaches storage?
Storage slows down (3x)
The blob storage becomes 3x slower.
Interviewer asks: File storage is slow. Which downloads can still be fast, and what makes that possible?
Live notifications hang
Whatever runs device notifications becomes 20x slower.
Interviewer asks: Notifications hang instead of failing cleanly. Should opening or saving a file wait for them, and where does the notification code live?
What a good design must do
- Downloads start within the latency target at peak
- The Monday surge passes
- Total monthly cost stays within $8,000
- Downloads are served through a CDN in front of storage
- Something saves files, and never lets two saves silently overwrite each other
- Something makes previews
- Files stay usable when live notifications hang
- The design explains how conflicting edits are detected and what the user sees