Whiteboard ScalePhoto SharingDesign Walkthrough

Photo Sharing System Design Walkthrough

Complete design walkthrough with animated diagrams, capacity math, API design, schema, and failure modes.

Solution PathTarget: 30 min
We designed Instagram photo sharing for 500M DAU with hybrid fanout (push for users under celebrity threshold, pull for 50M+ follower accounts) to avoid both 50M-write storms and 500-query fan-in. 820 TB/day of blob storage goes to S3 (cold tier after 30 days). PostgreSQL 64-bit time-sortable IDs across 8,192 shards eliminate coordination overhead. 2 TB Redis sorted-set feed cache across 50 nodes handles 350K peak reads/sec, with CDN absorbing 95%+ of photo delivery.
1/10
1.

What is Photo Sharing?

We are designing a photo-sharing platform where users upload photos, follow others, and browse a personalized feed. 1.3 billion photos uploaded every day. 500 million people open the app daily. The real challenge is the collision between storage scale and delivery speed.
Every photo must be stored, resized into 4 variants, and delivered via CDN in under 200ms. When a user with 50 million followers posts, we must decide: pre-compute 50 million feed entries (fast reads, slow writes) or compute on demand (slow reads, no write cost)?
That is the fanout problem applied to photos. Unlike text-only feeds, we also face a storage pipeline challenge: every upload triggers 4 resizes totaling 4.1 MB per photo.
At 200 million uploads/day, that is 820 TB of new storage daily. We solve two hard problems simultaneously: a write-amplified storage pipeline at planetary scale, and a read-optimized feed system handling 350K requests/sec.
1.3B photos/day, 820 TB/day storage, two hard problems: fanout at celebrity scale + storage pipeline at 4.1 MB per photo.
Instagram processes 1.3 billion photo uploads per day across 500 million daily active users. When a user posts a photo, we store the original in S3, generate 4 resolution variants (150px thumbnail, 320px small, 640px medium, 1080px full), push the photo ID into every follower's timeline cache, and deliver the image through a CDN with 95%+ cache hit ratio. The system sounds straightforward, but the real challenge is write amplification at scale: each single upload triggers 4 image resizes, a metadata write to PostgreSQL, and a fan-out to potentially millions of follower timelines, turning one user action into thousands of backend operations.
  • 200M photo uploads per day through a multi-resolution image pipeline generating 820 TB/day
  • Hybrid fanout pushes photo IDs to 500M timeline caches in Redis at 4 KB each, pulling for 10K+ follower accounts
  • We chose Instagram's 64-bit ID (not UUID) for time-sortability: 41-bit timestamp + 13-bit shard + 10-bit sequence
  • CDN delivers 95%+ of the 350K peak reads/sec, reducing origin load to ~17K QPS