Blog 20 — Instagram: Scaling to 1 Billion Users

1User uploads photo
2     │
3     ▼
4API Server → Media Service
5  ├── Resize to multiple resolutions (thumbnail, medium, original)
6  └── Store all versions in S3
7     │
8     ▼
9CDN (CloudFront) serves photos globally
10
11User metadata, follows, likes → PostgreSQL (sharded)
12Activity feed (notifications) → Cassandra
13Session data, counts → Redis

1Upload flow:
2  1. Client uploads to Instagram server
3  2. Server generates photo ID (Snowflake ID — timestamp-based)
4  3. Original stored in S3
5  4. Background job creates 3 resolutions:
6     thumbnail: 150x150
7     medium: 612x612
8     standard: 1080x1080
9  5. All 3 versions stored in S3
10  6. S3 URLs cached in CDN (CloudFront)
11
12Why multiple resolutions?
13  Thumbnail in feed: saves bandwidth for users scrolling
14  Full res only loaded when photo tapped
15  Mobile users on 2G get smaller images automatically

1Instagram used PostgreSQL from day 1 (similar to OpenAI!)
2
3Sharding by user_id:
4  users table: shard = user_id % num_shards
5  photos table: shard = owner_user_id % num_shards
6  follows table: shard = follower_user_id % num_shards
7
8Keep related data on same shard:
9  User + their photos + their follows → same shard
10  → Most queries touch only one shard → no cross-shard JOINs
11
12Snowflake IDs:
13  64-bit: [41 bits timestamp][10 bits shard_id][12 bits sequence]
14  Globally unique without coordination
15  Naturally time-ordered
16  Encode shard information directly in ID

1Normalized approach (bad for feed):
2  To show like count on photo:
3  SELECT COUNT(*) FROM likes WHERE photo_id = 123
4  → With billions of likes, this is slow
5
6Denormalized approach (Instagram's way):
7  Store like_count directly on photo row:
8  photo: { id: 123, url: "...", like_count: 45231 }
9
10  When user likes: UPDATE photos SET like_count = like_count + 1
11  When user unlikes: UPDATE photos SET like_count = like_count - 1
12
13  Feed query: SELECT * FROM photos WHERE ... ← no JOIN needed
14  Tradeoff: Counter might be slightly inaccurate under heavy concurrency (OK for likes)

1Instagram feed (simplified):
2  Pull model for all users (unlike Twitter's push/pull hybrid)
3
4  User opens feed:
5  1. Get list of users Alice follows (from follows table)
6  2. For each followee: get their last N posts
7  3. Merge and sort by timestamp
8  4. Cache result in Redis (TTL: 10 minutes)
9
10  Why pull works for Instagram:
11  → Photo feed doesn't need sub-second freshness
12  → Users check feed every few minutes, not seconds
13  → Simpler than Twitter's fanout complexity
14
15  For super-celebrities: pre-compute partial feed, merge at read time

1Notifications are time-series data:
2  "Alice liked your photo at 10:00"
3  "Bob commented at 10:01"
4  "Charlie followed you at 10:02"
5
6Perfect for Cassandra:
7  Partition key: user_id
8  Clustering key: notification_timestamp DESC
9  → Get last 20 notifications: single partition read, extremely fast
10
11Why not PostgreSQL for notifications?
12  10B users × 100 notifications each = 1 trillion rows
13  PostgreSQL can't handle this volume efficiently
14  Cassandra scales linearly: add nodes, add capacity