Design Instagram

#Problem Statement

Design a photo-sharing social network where users can post photos/videos, follow other users, and see a personalized feed of posts from people they follow.

📖

Real-world: Instagram is the legendary "tiny team, massive scale" story — at acquisition by Facebook for $1B in 2012 it had ~30M+ users and just 13 employees, running on AWS with a famously boring, reliable stack: PostgreSQL + Redis + Memcached, sharded across instances, with photos on S3 behind a CDN. They scaled the feed with fan-out-on-write (precompute each user's timeline) but had to special-case celebrities — fanning a Kardashian post to 300M followers on write is infeasible, so high-follower accounts use fan-out-on-read (the "hybrid" approach this design hinges on). Security angle worth raising: at this scale the social graph and media moderation (CSAM detection, abuse) become core infrastructure, not afterthoughts — content scanning and trust-and-safety pipelines run on every upload.

#Requirements

#Functional

• Upload photos/videos
• Follow/unfollow users
• Personalized feed (posts from followed accounts, ranked)
• Like and comment on posts
• Search users and hashtags
• Stories (ephemeral 24h content)

#Non-Functional

• 1B users, 500M DAU
• 100M photos uploaded/day
• 500M feed reads/day → 6k reads/s average; 100k peak
• Photo upload < 5s for standard connection
• Feed load < 500ms P99

#Core Design

Instagram is essentially a combination of three problems: media storage (YouTube-lite), social graph (Twitter follower graph), and news feed (Facebook news feed).

#Media Pipeline

Upload: chunked → S3 (raw)
Processing: async queue → image resize worker (thumbnail, 640px, 1080px) → S3
CDN: CloudFront/Akamai in front of S3

Each photo stored in 3 resolutions + thumbnail. CDN serves most traffic; S3 is origin.

#Social Graph

follows(follower_id, followee_id, created_at)
PRIMARY KEY (follower_id, followee_id)
INDEX (followee_id) -- for "who follows me"

At scale (Selena Gomez has 400M followers), this table is enormous. Use a graph DB (Neo4j) or a distributed KV store (Cassandra) partitioned by follower_id for "my following list" queries.

#Feed — Hybrid Fan-Out

Same hybrid approach as Facebook news feed:

Feed cache (Redis per user):
  feed:{user_id} → sorted set: score=rank, member=post_id
  
At feed load:
  1. Read pre-computed post IDs from Redis
  2. Fetch celebrity posts directly (last 50 from each followed celebrity)
  3. Merge + rank (recency + engagement)
  4. Hydrate post details (batch fetch from Posts DB)

#Stories

Ephemeral — auto-delete after 24h:

stories(story_id, user_id, media_url, created_at, expires_at)
INDEX expires_at  -- background job deletes expired stories
Seen tracking: Redis SET seen_stories:{viewer_id} → {story_id} (TTL 24h)

#Architecture

Upload Service → S3 → Transcoding queue → Media processor → S3 (resized) → CDN
Post Service → Cassandra (posts) → Fan-out worker → Feed cache (Redis)
Feed Service → Redis + celebrity post fetch → Rank → Hydrate → Response
Social Graph → Cassandra (follows) + Redis (hot follow counts)
Search → Elasticsearch (users, hashtags)
Notification → Push (APNs/FCM) / In-app

#Security Considerations

#Interview Tips