Capacity Estimation Worksheet

Build the mental model

Back-of-envelope capacity estimation is the discipline of turning a vague requirement into an order-of-magnitude number you can design against, in four moves. First, anchor on one stated or reasonable assumption — a DAU figure, an average payload size — rather than inventing several unknowns at once. Second, derive request rate by dividing daily volume by seconds in a day (~86,400), then multiply by a peak factor, since traffic clusters around study hours rather than spreading evenly — peak QPS is typically 2-3x the daily average, and provisioning for the average alone guarantees peak-hour outages. Third, derive storage by multiplying row count by average row size and projecting across the retention period the product actually needs, not an arbitrary one. Fourth, round aggressively — to powers of 10, or to numbers like 600 or 2,000 — because the entire exercise exists to catch a design that's off by 100x, not to produce a number precise to the byte. Treat every output as a sanity check, never as a capacity-planning contract.

Connect it to a real scenario

Suppose you're auditing Tutorial Platform's analytics pipeline, where an engineer sized the lesson-view event database off 'roughly a million events a day' without showing their work. Reviewing the design means re-deriving the number from stated assumptions — DAU, views per learner, event size — and checking whether the engineer's provisioned QPS accounts for peak traffic or only the flat daily average, and whether the retention period used for storage sizing matches what the product actually needs (raw events for 3 years, or aggregated summaries after 90 days?). A capacity estimate that can't be reconstructed from its inputs isn't a design decision — it's a guess wearing a design decision's clothes.

• Anchor every estimate on one stated assumption, then derive the rest — never invent multiple unknowns at once.
• Peak QPS is typically 2-3x the daily average because traffic clusters around peak hours, not evenly across the day.
• Round aggressively to powers of 10 or clean numbers — the goal is catching a 100x design error, not byte-level precision.

Try the working example

Assumption: 10,000,000 daily active learners (DAU)
Each learner views ~5 lessons/day
Each "lesson view" event ~200 bytes (event id, user id, lesson id, timestamp, metadata)

Step 1 - Daily event volume
10,000,000 DAU x 5 views/day = 50,000,000 events/day  (~5 x 10^7)

Step 2 - Average requests per second
50,000,000 events / 86,400 seconds/day ~= 578 events/sec
Round to a clean number: ~600 QPS average

Step 3 - Peak QPS
Traffic isn't flat across 24 hours - assume peak is 3x average (evening study rush)
600 QPS x 3 ~= 1,800 QPS peak
Round: ~2,000 QPS peak - this is the number the ingestion service must be provisioned for

Step 4 - Daily storage volume
50,000,000 events/day x 200 bytes/event = 10,000,000,000 bytes/day
= 10 GB/day

Step 5 - Storage projected over 1 year retention
10 GB/day x 365 days ~= 3,650 GB ~= ~3.65 TB/year
Round: ~4 TB/year - plan capacity around this order of magnitude, not the exact figure

The correct order-of-magnitude answer is roughly 50 million events/day, about 600 QPS on average and ~1,800-2,000 QPS at peak, and around 3.65TB (~4TB) of raw event storage for one year of retention.

Wikipedia — Fermi problem — System Design