Case study: Instagram (photo sharing)
Design photo sharing: a CDN carries the views, an object store keeps originals, async workers make every size, and time-ordered shard-aware IDs organise the metadata.
35 min9 steps
By the end you can
- Estimate storage growth, egress and origin load from the CDN hit rate
- Design an upload path that acknowledges fast and processes asynchronously
- Explain Instagram's 64-bit IDs and why sharding by user suits photo metadata
- Predict the effect of a CDN outage, an upload spike and a slow object store
Requirements
Features
- Captioned uploads, multiple sizes, user photo lists
Targets
- Global views p99 <200 ms; durable uploads within seconds
Workload
- Hundreds of views/upload; thumbnails may lag
Estimates
Uploads
1,160/s
100M/day; peak 3k/s
Storage
90 PB/year
100M * 2.5 MB * 365
Views
580k/s
500M users * 100 / 86,400
Egress
87 GB/s
580k * 150 KB; 700 Gbit/s
Origin
29k/s
95% CDN hits -> 5% misses
Resize CPU
140 cores
1,160/s * 120 ms CPU
API
Upload
POST /v1/media; resumable chunks/pre-signed URL -> 201, sizes pending
View
GET /p/{photoKey}_{size}.jpg; immutable CDN key
List
GET /v1/users/{id}/media?cursor=
Edit
New object key; update metadata pointer
Data model and IDs
Media
User-sharded metadata; database stores object keys
Photos
Immutable object bytes; lifecycle tiers
64-bit ID
41 timestamp + 13 logical shard + 10 sequence bits; sortable and routable
High-level design
Order the upload path.
- 1The API enqueues a resize job and returns 201
- 2The client uploads the original in resumable chunks
- 3The API stores the original in the object store
- 4A worker generates each size and stores it
- 5The API inserts the media row on the user's shard
Deep dive: serving images
Edges
- Popular photos hit; old-photo tail misses
Shield
- Coalesce simultaneous edge misses into one origin fetch
Cold tier
- Haystack packs photos; f4 erasure-codes warm bytes
Alternatives
Own serving
- Control; costly global 700 Gbit/s egress
Synchronous resize
- All sizes ready; upload CPU saturates during spikes
Managed blobs
- Lifecycle tiers; less operational work
Own blobs
- Haystack/f4 economics at very large scale
Failure scenarios you can run
Inject
Edge fails until DNS TTL expires
Observe
Origin receives every view
Recover
Object reads and origin egress surge
Inject
Uploads x3
Observe
Durable acceptance stays fast
Recover
Resize queue grows; scale workers on depth/age
Inject
Latency x6
Observe
CDN hits unaffected
Recover
Misses slow; some exceed storage timeout
Wrap up
Persist
Original before 201; sizes asynchronous
Serve
Immutable URLs, CDN, shield, storage tiers
Watch
Hit rate, origin egress, resize age; user-sharded sortable IDs
Then score each stage from 1 to 4.
Answer this step to continue.