Run the back-of-envelope drill — numbers before architecture

At a glance

Learning objectives

• Estimate QPS, storage per day, and retention footprint from a workload description
• Apply peak-versus-average factors instead of quoting averages alone
• Ground an estimate in a real deployed reference architecture

What you need

• A calculator or the worksheet in this lesson
• A workload sentence to estimate, e.g. 100M events/day at 1 KB each

Steps

1. Locate the drill in the study guide — back-of-envelope estimation is one of the three things the Primer exists for, alongside scaling vocabulary and worked design exercises. That placement is deliberate, numbers come before boxes. (from ref-system-design-primer )
2. Take the on-ramp seriously — the Primer is described as the standard on-ramp for the estimation and tradeoff vocabulary this stage's interview path needs, so the drills here are the path's entry fee, not an aside. (from ref-system-design-primer )
3. Practice against worked exercises, not invented ones — the Primer's third pillar is worked design exercises, and each one begins with the same estimation step you are drilling here. (from ref-system-design-primer )
4. Ground the numbers in deployed patterns — AWS's collection of architecture diagrams and best-practice guidance (Well-Architected pillars, serverless data lake patterns) is exactly where a sizing claim stops being hypothetical. (from ref-aws-arch-center )
5. Use architectures as citable evidence — reference architectures are called the closest thing to citable evidence when an answer needs a real-world precedent, so attach one to every estimate you defend. (from ref-aws-arch-center )

Check yourself

• 100M events/day at 1 KB each is ~100 GB/day raw — you can get there with powers of two in under a minute.
• You quote peak QPS (2–3x average) before anyone asks, because averages hide the load that actually breaks systems.

Worked example

# Back-of-envelope worksheet — powers of two + QPS/storage math
P2 = {("1 KB"): 2**10, ("1 MB"): 2**20, ("1 GB"): 2**30,
      ("1 TB"): 2**40, ("1 PB"): 2**50}

def estimate(events_per_day, bytes_per_event, retention_days, peak_factor=3):
    qps_avg  = events_per_day / 86_400
    qps_peak = qps_avg * peak_factor
    raw      = events_per_day * bytes_per_event * retention_days
    return {"avg_qps": round(qps_avg), "peak_qps": round(qps_peak),
            "storage_TB": round(raw / 2**40, 1)}

print(estimate(events_per_day=100_000_000,
               bytes_per_event=1_000,
               retention_days=730))

1. Throughput   — avg QPS and peak QPS (peak = 2-3x avg)
2. Storage/day  — events * bytes per event
3. Retention    — storage/day * retention days (+ replication factor)
4. Precedent    — one reference architecture that ships this shape

Sourced from

• The System Design Primer
• AWS Architecture Center

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• Averages hide peaks — quote both, and size for the peak.
• Retention is the silent multiplier — 100 GB/day is 36 TB/year before replication.
• An estimate without a deployed precedent is an opinion — cite a reference architecture.

Production considerations

• Re-run the estimate after every 2x growth event — the worksheet is cheap, the surprise is not.
• Keep the arithmetic next to the architecture diagram so the two are reviewed together.

Diagram

back-of-envelope drill
   |
   |- workload sentence: 100M events/day, 1 KB each
   |
   |- events/sec   --> 100e6 / 86,400  ~ 1,160 avg  ~ 3,500 peak
   |- storage/day  --> 100e6 * 1 KB    ~ 100 GB
   |- retention    --> * 730 days      ~ 73 TB  (+replication)
   |
   |- every number --> grounded in a reference architecture
   |
    --> numbers before boxes, always

Registry stats