1Context and scope
People open their feed far more often than they post. A post has to reach every follower’s feed, the feed has to open in a few hundred milliseconds, and a like has to count instantly without touching the main database. This design is the API traffic around the product: feed loads, profile views, likes and posts, with media bytes on a CDN. It is based on public write-ups by Instagram and Meta engineers, scaled to what a browser simulates in a few seconds.
2Goals and non-goals
Goals
- 4,000 requests a second: 70% feed loads, 10% profile views, 15% likes, 5% posts.
- Success at least 99%, p99 at most 500 ms, Apdex at least 0.90.
- Posts fan out to followers asynchronously; nothing is lost and nothing runs twice.
Non-goals
- Stories, reels and direct messages.
- Media bytes themselves: the CDN serves them; this is the API traffic around them.
- Multiple regions and data residency.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Feed loads | ≈ 2,800/s | 70% of 4,000 |
| Timeline cache | 32 GB, 20M timelines, 10 min TTL | Zipf 1.1: active users dominate, so most loads hit |
| Timeline store | 128 partitions × 2,000 ops/s | 256,000 ops/s for cache misses and fan-out writes |
| Ranker | 1,024 slots, 64 vCPU, 3 ms CPU | 2,800 × 3 ms ≈ 8.4 vCPU busy; 2,800 × 15 ms ≈ 42 slots |
| Likes | ≈ 600/s | on 64 Cassandra partitions, Zipf 1.2: viral posts are hot keys |
| Posts | ≈ 200/s | each: one S3 write, one resize (60 ms CPU), one Postgres write, one fan-out job |
| Fan-out workers | 256 consumers at ≈ 10 ms | about 25,000 jobs a second of headroom |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Instagram design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.