Instagram / Photo + Reels Sharing

Design a photo + short-video sharing app at planet scale. 2B MAU, ~95M uploads/day, read-heavy ~100:1. Home feed blends followed accounts with algorithmic recommendations; reels feed is purely algorithmic.

Time budget: 45 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.

Hint 1

Split the problem into (a) media pipeline, (b) feed, (c) reels ranker. They have different architectures and different read/write ratios.

Hint 2

For feed: hybrid fan-out. Push-on-write to normal users, pull-on-read for celebrities. The threshold is the design choice.

Hint 3

For media: direct-to-S3 uploads with pre-signed URLs; async transcoding; CDN with tiered storage for cost.

• +1 Back-of-envelope: 95M uploads/day → ~1,200/sec writes, ~290k feed loads/sec, ~3 PB/day media
• +2 Media pipeline: direct-to-S3 via pre-signed URLs; async transcoder emits 5–10 derivatives; CDN lazy-pulls on first view
• +2 Hybrid fan-out explicitly: push for ≤ N-follower users, pull-on-read for celebrities (N ≈ 100k follower threshold)
• +1 Feed storage: Redis sorted-sets per user (timeline); posts sharded by user_id in Cassandra
• +1 Reels vs home feed are separate products: different ranker, different candidate pool
• +1 Storage tiering: hot (SSD) / warm (HDD) / cold (Glacier) — discusses cost saving math
• +1 Mentions collapse_id or equivalent for dedup across retries; idempotency on PUT
• +1 Addresses failure modes: celebrity hot-key on feed cache; upload token abuse; CDN cache miss cascade

Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.

• Proposes storing photo bytes in Postgres / MySQL
• Uploads go through app servers (byte proxy) instead of direct-to-S3
• Fan-out naively to all followers regardless of celebrity status
• Synchronous transcoding blocking the upload request
• Ignores feed read QPS (290k/sec) — treats as just a write problem