Design Instagram
The setup
"Design Instagram. Focus on: photo upload + storage, the user's feed (posts from people they follow), and the user profile timeline. 2 billion users; 100M new posts/day; users open the app ~10× per day."
What's different from Twitter: the feed problem is the same structurally, but the data is media-heavy (photos, not text). Storage and CDN dominate the cost; the feed-computation problem is solved the same way. The interview test is whether you can recognize this and focus your design on what's actually different.
Clarifying questions
| Question | Story answer |
|---|---|
| Posts have multiple photos / carousels? | Single photo for v1. Carousels deferred. |
| Video posts? | Out of scope; just static photos. |
| Stories (24h time-limited content)? | Mention at end; separate sub-architecture. |
| What sizes/variants do we generate from upload? | Thumbnail (150×150), medium (640×640), full (1080×1080). |
| Feed ordering: chronological or ML-ranked? | Chronological for v1; ML-ranked is a separate problem. |
Capacity estimation
Photo upload: 100M posts/day × ~1 MB/photo (after compression) = 100 TB/day raw With 3 variants (thumbnail, medium, full): ~3× = 300 TB/day Per year: ~110 PB Feed reads: 2B users × 10 opens/day = 20B feed reads/day = ~230K/sec average Peak (during events): ~1M/sec Photo download bandwidth: Feed loads ~20 photos × ~200 KB each = ~4 MB per feed render 230K reads/sec × 4 MB = ~900 GB/sec average = ~7 Tbps (CDN handles 95%+ from edge cache)
What's identical to Twitter (don't re-design)
Same feed problem; same hybrid push-pull architecture; same celebrity threshold; same Redis-backed inboxes; same Cassandra-backed post storage. The metadata flow is essentially identical. Don't waste interview time re-deriving these.
What's different: photo storage and serving
Each photo is ~200-500 KB (after compression) for a typical Instagram crop. Photos are stored in object storage; metadata in a database.
| Storage decision | Choice | Why |
|---|---|---|
| Object store for binary photos | S3-class with regional replication | Cheap per GB; massively scalable; handles 100 TB/day uploads trivially |
| Variant generation | Async pipeline on upload (Lambda/serverless or worker pool) | Generate thumbnail/medium/full once; cache forever; viewer requests via direct URL |
| Photo URLs | Signed URLs with long expiry; CDN-fronted | Direct CDN serving without authenticating each request through app tier |
| Photo metadata | Separate from binary; in main posts DB (Cassandra) | Posts row contains photo URLs to each variant; client picks size based on use case |
Design Decision 1: image processing pipeline
Upload flow:
1. User uploads photo via multipart POST → CDN edge upload endpoint
2. Direct upload to S3-class storage in original resolution
3. S3 event → Kafka → image-processing workers
4. Worker:
a. Resize to thumbnail (150×150)
b. Resize to medium (640×640)
c. Resize to display (1080×1080)
d. Compress (WebP or JPEG)
e. Write each variant to S3 as separate object
f. Update posts metadata: post X has variants {thumb_url, med_url, full_url}
5. Push notification to user's followers (fan-out for feed) — only after variants ready
Processing cost: ~100M photos/day × ~50ms processing each (per variant) × 3 variants = 15M sec of compute = ~170 cores running continuously. Trivial in a worker pool. Use GPU/accelerated processing for high-volume image work to reduce cost.
Design Decision 2: CDN strategy for photos
~95% of photo views are from CDN edges. Same pattern as YouTube:
- Edge POPs cache thumbnails (smaller, hotter — feed scrolling)
- Medium variants cached at edges for visible-in-feed
- Full variants cached at mid-tier (less frequently shown in detail view)
- Pre-warming for celebrity posts (push to edges proactively)
Cost analysis: Instagram's bandwidth bill is dominated by photo egress. At ~7 Tbps sustained, at typical CDN pricing (~$0.05/GB), that's ~$30M/day. Even with custom CDN economics (negotiated rates, peering, embedded ISP caches), bandwidth is the largest single line item by far.
Cross-examination round 1: celebrity posts
A: Identical to Twitter celebrity handling. Feed reader merges precomputed inbox + live-fetch of celebrity posts. Just the data is heavier (photo URLs not text). The feed metadata is small (post IDs + variant URLs); the heavy lifting is the photo bytes themselves, which go through CDN.
Cross-examination round 2: stories (24h ephemeral content)
- Storage with TTL: stored separately (e.g., separate S3 bucket with 24h lifecycle policy) so they auto-delete.
- Different access pattern: very hot for 24h then completely cold. Aggressive edge caching is essential because popularity is concentrated.
- Different feed: stories aren't part of the timeline feed; they have their own "story tray" UI. Backend: separate stories service with its own feed-assembly logic.
- View tracking: who has viewed a story is recorded (for the "viewers" list creators see). Different schema; needs view writes.
Takeaway
Once you've designed Twitter, Instagram is mostly a media-heavy variant of the same pattern. The architecture is the same; the bytes are bigger. The fundamental cost shifts from feed computation to media delivery. CDN strategy and image pipeline optimization become the primary engineering investments. The systems-design lesson: when traffic shape resembles a known pattern, reuse the architecture and focus on what's actually different. Don't re-derive what's already solved; spend interview time on the genuinely novel parts (media handling, CDN economics, stories' TTL pattern).