· SWE Editorial · System Design · 4 min read
Design a News Feed: Capacity Estimation
Back-of-envelope capacity estimation for the news feed system design interview: DAU assumptions, storage per post, cache sizing for hot users, and QPS peaks, updated July 2026.
Capacity estimation is the step candidates most often rush or skip, yet it’s what justifies every architectural choice that follows — why you need a cache layer, why fanout-on-write is viable, and how large your cluster needs to be. This article walks through a full estimation pass for a news feed system, with the assumptions stated explicitly so you can adapt the numbers to whatever scale the interviewer gives you.
Setting DAU Assumptions
Start by anchoring to a concrete user base, since every downstream number depends on it. A reasonable mid-size social platform assumption:
- Daily Active Users (DAU): 100 million
- Average posts per user per day: 0.5 (half of users post something on a given day)
- Average feed opens per user per day: 10
- Average follows per user: 200
These are round numbers you state out loud and adjust if the interviewer pushes back — the goal is defensible math, not the “correct” number.
Write Volume
- New posts per day: 100M DAU × 0.5 posts = 50 million posts/day
- Posts per second (average): 50M / 86,400s ≈ ~580 posts/sec
- Peak write QPS (assume 3x average at peak hours): ~1,740 posts/sec
Fanout Write Volume
This is the number that makes the celebrity problem concrete. If every post fans out to all followers:
- Average fanout writes per post: 200 followers (using the average-follows assumption as a proxy for average followers in a roughly symmetric graph)
- Total fanout writes/day: 50M posts × 200 = 10 billion feed-cache writes/day
- Fanout writes per second (average): 10B / 86,400 ≈ ~115,000 writes/sec
This single number is why the hybrid fanout model exists: a handful of celebrity accounts with 50 million followers each would individually generate more fanout writes than this entire average, which is why those accounts get carved out to fanout-on-read.
Read (Feed Load) QPS
- Feed reads per day: 100M DAU × 10 opens = 1 billion feed requests/day
- Average read QPS: 1B / 86,400 ≈ ~11,600 requests/sec
- Peak read QPS (3x average): ~35,000 requests/sec
| Metric | Average | Peak (3x) |
|---|---|---|
| Post writes/sec | 580 | 1,740 |
| Fanout cache writes/sec | 115,000 | 345,000 |
| Feed reads/sec | 11,600 | 35,000 |
| Read:Write ratio | ~20:1 | ~20:1 |
The read:write ratio confirms the earlier architectural assumption — this is an overwhelmingly read-heavy system, which is why nearly every design decision (caching, precomputed timelines, CDN for media) optimizes for read latency over write throughput.
Storage Per Post
Estimate storage for a single post record:
- Post ID: 8 bytes
- Author ID: 8 bytes
- Text content: ~280 bytes average (short-form) to ~2KB (long-form)
- Metadata (timestamp, visibility, media references): ~100 bytes
- Total per post: roughly 1KB (excluding media, which lives in blob storage/CDN, not the post record itself)
Total post storage growth per day: 50M posts × 1KB = ~50GB/day of structured post metadata, or roughly 18TB/year before replication factor. With a typical 3x replication factor for durability, budget ~54TB/year in raw storage for post metadata alone — media assets are estimated separately against object storage costs, which typically dominate total storage spend by an order of magnitude.
Cache Sizing for Hot Users
The feed cache needs to hold, for every active user, a recent window of post IDs (not full post content — just IDs, to keep entries small).
- Assume each cached feed entry holds the last 500 post IDs per user (enough for several days of scrolling before falling back to a cold rebuild).
- Per-entry size: 8 bytes (post ID) + 8 bytes (timestamp score) = 16 bytes.
- Per-user feed cache size: 500 × 16 bytes = 8KB.
- Total cache size for 100M DAU: 100M × 8KB = ~800GB.
This fits comfortably across a sharded Redis cluster (even a modest cluster of a dozen nodes with 64-128GB RAM each handles this with headroom), which is why fanout-on-write is economically viable at this scale — the cache footprint stays in the hundreds of gigabytes, not petabytes.
| Resource | Estimated size |
|---|---|
| Feed cache (100M users, 500 entries each) | ~800GB |
| Post metadata storage (1 year, 3x replication) | ~54TB |
| Daily fanout write volume | ~10 billion writes |
| Peak read QPS | ~35,000/sec |
Stating Assumptions Out Loud
The specific numbers matter less than the discipline of stating assumptions explicitly, deriving each subsequent number from the last, and sanity-checking the result (does 800GB of cache sound reasonable for a cluster? does 35K QPS sound survivable with standard horizontal scaling?). Interviewers are evaluating your estimation process, not grading against a hidden answer key.
For a repeatable framework you can apply to any system design capacity estimation question — not just feed — The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) includes a dedicated estimation template with the standard unit conversions memorized so you’re not doing long division on the whiteboard.
Common Estimation Mistakes
- Forgetting to separate average QPS from peak QPS — interviewers almost always ask about peak load.
- Estimating post storage without accounting for replication factor.
- Ignoring media storage entirely, or conflating it with structured post metadata.
- Failing to connect the fanout-write number back to the celebrity problem discussion — this is the payoff of doing the math in the first place.
Capacity estimation isn’t a box-checking exercise before the “real” design work — the numbers you derive here directly justify the fanout strategy, cache sizing, and sharding scheme you’ll propose in the deep-dive portion of the interview.