Home / Blog / System Design Capacity Estimation Cheat Sheet

System Design Capacity Estimation Cheat Sheet

Published 2026-09-30 · Luna Interview

System design capacity estimation is not about perfect arithmetic—it is about showing you size components before you invent them. This cheat sheet gives you a repeatable back-of-envelope flow, talk tracks, and the mistakes that make estimates look fake.

Why interviewers ask for numbers

They want to see whether you:

• Translate product assumptions into QPS, storage, and bandwidth
• Pick orders of magnitude (10^3 vs 10^6) confidently
• Use estimates to justify cache, shard, or async choices
• Notice when a design is overkill for the load

A wrong number with clear assumptions beats a precise number from nowhere.

The five-number starter pack

Write these on the board early:

1. DAU / MAU (or active devices)
2. Read/write ratio
3. Peak QPS (not only average)
4. Payload size (avg request/response or object size)
5. Retention (how long data lives)

Talk track:

“I’ll assume 10M DAU, 1:9 write/read, peak 10× average, 2 KB average object, 1 year retention—call out if you want different assumptions.”

Invite correction. Collaboration is part of the grade.

Core formulas (memorize the shape)

Average QPS

QPS ≈ (DAU × actions_per_user_per_day) / 86400

Peak QPS

Peak ≈ average × peak_factor   # often 3–10×; state your factor

Storage

Storage ≈ objects_per_day × bytes_per_object × retention_days × replication_factor

Bandwidth

Egress ≈ QPS × response_bytes
Ingress ≈ QPS_write × request_bytes

Machines (very rough)

Instances ≈ Peak_QPS / QPS_per_instance   # with headroom 2–3×

Say headroom out loud. Pure 100% utilization is not a plan.

Order-of-magnitude shortcuts

Round aggressively: “about 200 QPS” not “187.3 QPS.”

Worked mini-example (photo metadata service)

Assumptions: 5M DAU, each uploads 0.2 photos/day average, reads 20× writes, photo metadata 1 KB, blobs elsewhere, retain metadata 5 years, peak 5×.

• Writes/day ≈ 5e6 × 0.2 = 1e6 → ~12 write QPS average → ~60 peak
• Reads/day ≈ 20e6 → ~230 read QPS average → ~1.2k peak
• Metadata/day ≈ 1e6 × 1 KB ≈ 1 GB/day → ~1.8 TB/year → ~9 TB in 5 years before replication
• With 3× replication ≈ ~27 TB → still one careful datastore generation, not petabyte drama

Then justify: cache hot reads; object store for blobs; DB for metadata.

What estimates should unlock in the design

If you estimate 50 QPS and propose 64 shards, expect pushback—good.

Peak events and batch jobs

Not all load is user QPS. Call out separately:

• Cron / ETL windows that rewrite large tables at night
• Fan-out (one write triggers N notifications)—multiply carefully
• Retries (client retries can 2–3× apparent QPS during blips)
• Admin exports that scan huge ranges—isolate them

Talk track:

“User peak is about 1.2k read QPS; notification fan-out is async via a queue so it won’t multiply API QPS directly.”

If fan-out is synchronous, your estimate must include it—or you redesign it to be async.

Common mistakes

• Using average QPS to size for launch-day Super Bowl peaks without a factor
• Forgetting replication and indexes in storage
• Mixing bits and bytes
• Precision theater (eight digits) with fictional inputs
• Never revisiting estimates after the design changes
• Estimating only storage when the bottleneck is clearly CPU or fan-out

First five minutes flow

1. Clarify product actions that generate load
2. Lock assumptions with the interviewer
3. Compute QPS → storage → bandwidth (pick the relevant ones)
4. Circle the bottleneck guess
5. Start the architecture with that bottleneck in mind

Freeze recovery

1. Stop drawing boxes
2. Write DAU and actions/day
3. Do QPS only—ignore storage until QPS lands
4. Round to one significant figure
5. Ask interviewer if assumptions are OK

Talk track:

“I’m going to land peak read QPS first; that drives cache and API tier sizing.”

Soft practice note

Capacity math is a calm ritual you can rehearse. If you want a Chrome side panel to practice saying assumptions → formulas → design implications under time pressure, Luna Interview supports that rehearsal loop. Use it to build fluency—not to fake production experience or to violate interview rules.

Day-of checklist

• [ ] Assumptions written and confirmed
• [ ] Average and peak QPS
• [ ] Storage with retention × replication
• [ ] Bandwidth if media/egress matters
• [ ] Headroom stated
• [ ] Estimate tied to one architecture choice

Estimate to decide—not to decorate the whiteboard.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.