How do you estimate capacity (RPS/storage/bandwidth) for a social app?

Capacity estimation is the foundation of scalable architecture. In a system design interview, when asked to design a social app, you are expected to estimate Requests per Second (RPS), storage, and bandwidth accurately. This is not guesswork but a structured method to convert user assumptions into real capacity numbers. Let’s break it down step by step and see how professionals and FAANG engineers do it.

Why It Matters

Accurate capacity planning ensures your system scales cost-effectively and meets SLAs under load. It helps you size databases, caches, CDNs, and queues properly. Interviewers love candidates who reason quantitatively — it shows you can design data-driven systems, not just guess architectures.

How It Works (Step-by-Step)

Here’s a systematic approach to estimate RPS, storage, and bandwidth for a social app like Instagram or Twitter.

Define user base and activity
- Daily Active Users (DAU): e.g., 10 million
- Sessions per user per day: 4
- Peak factor: typically between 2–5
List major actions per user
- Feed views: 3 per session
- Likes: 20 per day
- Comments: 2 per day
- Posts: 0.2 per day
- Average followers: 150
Estimate total actions per day
- Feed views = DAU × sessions × views per session
- Likes = DAU × likes per user per day
Convert to RPS
- Average RPS = total events ÷ 86,400
- Peak RPS = Average RPS × peak factor
Model fan-out and read/write ratio
- Post write fan-out = followers × posts per day
- Feed reads mostly hit caches
- Origin load = RPS × (1 – cache hit ratio)
Estimate storage
- Data growth = records/day × average size × replication factor
- Media (images, videos) dominate storage
Estimate bandwidth
- Egress = downloads × average size × (1 – CDN hit ratio)
- Ingress = uploads × average size
Apply Little’s Law for concurrency
- Concurrency = RPS × avg response time (sec)
- Helps size server threads and DB connections
Include replication and safety margins
- Add 30–50% buffer for traffic spikes
- Factor 2× or 3× for data replication and backups
Validate assumptions

Always write down your assumptions — interviewers may challenge them

Real World Example

A photo-sharing app with 10M DAU, 4 sessions/day, and 3 feed reads/session:

Total feed reads/day = 10M × 4 × 3 = 120M
Average RPS = 120M ÷ 86,400 ≈ 1,390
Peak RPS (×3) = 4,170
Cache hit ratio 80% → Origin RPS ≈ 834

For uploads:

Posts/day = 2M (0.2 × 10M)
Images = 25% of posts (400 KB each)
Videos = 5% of posts (10 MB each)
Storage/day ≈ 0.25 × 2M × 400 KB + 0.05 × 2M × 10 MB = ~1.2 TB/day

Over one year (with replication factor 2): ≈ 900 TB total media data.

Common Pitfalls or Trade-offs

Underestimating fan-out Many candidates forget follower amplification. A single post can trigger hundreds of timeline writes or reads. Always clarify push vs pull feed models.

Ignoring peak load Design for the 99th percentile. A system that survives average load but fails at peak is not scalable.

Neglecting cache and CDN ratios Cache hit ratios can vary dramatically by user or region. Model both hit and miss paths.

Storage replication overhead Data is never stored once. Add space for backups, indexes, and metadata.

Ignoring background jobs Notification fan-outs, analytics pipelines, and recommendation updates add 10–20% extra load.

Skipping Little’s Law Failing to estimate concurrency leads to under-provisioned connection pools and thread exhaustion.

Interview Tip

When asked to “design Instagram,” start by saying: “I’ll begin by estimating capacity. How many reads and writes per second we need to support.” Then walk through DAU, actions, and peak factors before jumping into architecture. This structured thinking impresses interviewers immediately.

Key Takeaways

Always estimate capacity before final architecture.
Use DAU, sessions, and actions to derive RPS.
Separate reads, writes, and fan-out effects.
Include replication, caching, and safety buffers.
Use Little’s Law to reason about concurrency.

Table of Comparison

Method	Best For	Inputs	Strengths	Limitations
Top-down estimation	Interviews and early planning	DAU, actions, peak factor	Quick and intuitive	Misses internal dependencies
Bottom-up endpoint analysis	Service sizing and SLOs	Per-API metrics	Maps to real system behavior	Needs telemetry
Load testing	Pre-launch validation	Real or synthetic traffic	Captures burstiness	Expensive and time-bound
Analytics-based	Production tuning	Observed metrics	Grounded in data	Lagging indicator for growth

FAQs

Q1. How do I pick a peak factor for social apps?

Use 3× for most global apps. For time-sensitive usage (like sports events), use up to 5×.

Q2. How do I estimate media storage growth?

Compute posts/day × average media size × replication × retention period.

Q3. What cache hit ratio should I assume?

For feeds, 70–90% is typical. Always mention it explicitly in interviews.

Q4. How to factor in CDN usage?

Egress bandwidth = total media × (1 – CDN hit ratio). Use 90–95% for image/video heavy apps.

Q5. How to validate my assumptions?

Use telemetry or analytics to compare real vs estimated load after launch.

Q6. Why use Little’s Law in interviews?

It shows quantitative maturity. You understand concurrency and queue sizing.

Further Learning

Build mastery in these calculations and scalable design patterns with Grokking System Design Fundamentals.

To go deeper into high-traffic system sizing and feed architecture, check Grokking Scalable Systems for Interviews.

For complete interview walkthroughs and FAANG-style examples, explore Grokking the System Design Interview.