System 12.7 — Instagram (Media Sharing)
In one line
Twitter + a compressed media pipeline: upload, transform (resize/filter), and serve from CDN via signed URLs.
Think of it like this
Twitter with photos and videos attached, meaning the hard problem shifts from 'text fan-out' to 'how do we resize, store, and speedily deliver millions of images and videos without our storage bill exploding.'
Key ideas
- 01
Write path: upload → object store (raw) → async processing pipeline → thumbnails/resized variants → CDN invalidation.
- 02
Class design: media microservice, feed (same push/pull as Twitter), user/graph, search/discovery.
- 03
Scale: 100M uploads/day × ~1MB → 100TB/day storage, ~1.2k uploads/s + big read-to-write ratio.
- 04
The CDN is the answer to read bandwidth: images/videos served edge-first; presigned PUTs let clients upload direct.
- 05
Async pipeline: raw → transcode (ffmpeg) → variants (360p/720p/1080p) → metadata update → cache warm → notify.
- 06
Failures: transcode worker crash → requeue; corrupted file → DLQ + alert; CDN purge on new variant.
- 07
Extras: likes/comments (similar to Twitter), stories (TTL-based, read-heavy), reels (video + recommendation).
- 08
Interview: match features to modules quickly, spend the minutes on the media pipeline and feed choice.
Code & diagrams
The write path is a factory line; the read path is almost entirely CDN.
Explain without notes
Trace one 4K reel upload end-to-end: which services touch it, in what order, and where would queue backups show?
Practice
Draw the transcode pipeline with variants, DLQ, and a CDN invalidation step.
Trade-offs
- ↔
On-device resizing (fast, cheap, inconsistent) vs server transcode (quality, cost, latency) — pick for v1 and justify.
Completion checklist
I can present the media ingest pipeline + CDN serving + feed reuse confidently.