Back-of-the-envelope estimation

01Choose the question before the arithmetic

A note service must save new notes, keep them for a year and answer reads. Calculate the quantities that change those decisions:

• Count writes to estimate how much saving work arrives each second.
• Count retained bytes to plan storage.
• Count repeated reads to decide whether reusable copies could save work.
• Count attachments separately if a few files are much larger than notes.

Use these exercise assumptions:

1. Two million people use the service each day.
2. Each creates four notes/day.
3. Each note, including required metadata, averages 2 KB.
4. Notes are retained for 365 days.
5. Busy-period traffic is assumed to be five times the daily average.

State units before calculating. Here 1 KB is 1,000 bytes, 1 GB is one billion bytes and 1 TB is one trillion bytes. Binary units such as mebibytes use a different convention.

Assumptions are not measurements. An average 2 KB record can hide large attachments, and a fivefold peak must be checked against real traffic before provisioning. Keep each input beside its calculation so another engineer can change it.

02Carry one workload through the units

Calculate writes and text storage separately:

1. **Daily writes:**2 million users ×4 notes =8 million writes/day.
2. **Average rate:**8 million ÷86,400 seconds ≈92.6 writes/second.
3. **Planning peak:**92.6 ×5 ≈463 writes/second; rounding to about 465 is reasonable for planning.
4. **Daily text:**8 million ×2,000 bytes =16 GB/day.
5. **Annual text:**16 GB ×365 =5.84 TB.
6. **Three full text copies:**5.84 TB ×3 =17.52 TB before supporting structures and spare space.

A note write may also check ownership, update an index and wait for copies to be saved. Measure that complete operation before converting requests/second into a machine count.

Now calculate an assumed ten reads per write:

1. Eight million writes ×10 =80 million reads/day.
2. Divide by 86,400 to get about 926 reads/second.
3. At 2 KB/read, average body transfer is about 1.85 MB/second before network-format overhead.

Finally, suppose 1% of writes include a 5 MB image:

1. Eight million ×1% =80,000 images/day.
2. Multiply by 5 MB to obtain 400 GB/day.
3. Compare 400 GB of images with 16 GB of note text. The image path carries 25 times as many new bytes.

Plan image transfer and storage separately from small note records. The calculation explains that choice without requiring a complicated identifier or partitioning scheme.

03Check concurrency, headroom, and uncertainty

Start storage planning with application records, then add what the chosen system actually retains:

• Replicas keep additional current copies.
• Indexes add structures used to find records.
• Recovery logs retain changes needed after failures.
• Backups retain earlier recoverable history under their own retention rule.
• Compression may reduce stored bytes; metadata and spare capacity add more.

Do not replace those separate estimates with an unexplained universal multiplier.

Next distinguish arrival rate from simultaneous work. If 500 requests arrive each second and spend 0.2 seconds in the system on average, a stable system has about 500 × 0.2 = 100 requests being handled or waiting. This is average concurrency. Use the same start/end points for both measurements. It does not calculate p99 and does not make an endlessly growing queue stable.

Check one failure using surviving capacity:

1. Four machines share 1,200 requests/second, so each receives 300/second while all are healthy.
2. Lose one machine without changing demand. Each of three survivors receives 400/second.
3. If testing found that a machine meets the latency target only up to 350/second, this fleet cannot safely cover the failure at that load.

Finish with the consequence and next evidence:

• Images dominate bytes, so size their transfer and storage separately.
• A modest write count alone does not prove a need for many database shards.
• Measure the busiest users, record sizes, complete query work and peak shape.
• If an input range gives the same conclusion, use that conclusion and measure the uncertain value next.