Back-of-Envelope Estimation and Capacity Model Template

Reference latency and unit tables, assumptions register, QPS, storage, bandwidth, cache, server and cost formulas, worked example, sensitivity, traceability

Conception systèmeCompletJeff Dean latency numbers (LADIS 2009)back envelope estimation mathMis à jour 22 oct. 2026

Ouvrir dans l'éditeurTélécharger .md

Mode d'emploi: Use it when a design needs defensible numbers before choosing components. Fill the assumptions register with sources and confidence first, then derive peak QPS, storage, bandwidth and server counts with the formulas. The main pitfall is sizing from averages or trusting 2009 reference latencies instead of benchmarks of your own hardware.

Aperçu

Capacity Estimation Worksheet: [System or feature name]

Back-of-the-envelope estimation and capacity model for a new system or a major change. It gives reference numbers (latency, throughput, storage units, time and availability conversions), a repeatable method, formulas for average and peak QPS, storage growth, bandwidth, cache size, server count and cost, a fully worked example, a sensitivity analysis, common pitfalls and a traceability table that carries each estimate into the design document. Reference latencies follow the widely circulated "numbers everyone should know" list presented by Jeff Dean (Google) in 2009; they are orders of magnitude, not measurements of your hardware. Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	[CAP-EST-001]
System / feature	[Photo sharing service]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@owner]
Reviewers	[@reviewer-1], [@reviewer-2]
Last updated	YYYY-MM-DD
Classification	[Internal]
Planning horizon	[12 months from launch]
Linked design document	[SDD-PHOTO-001]
Assumptions last validated against production data	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
Tech lead	[@name]	[Approved / Changes requested]	YYYY-MM-DD
SRE / capacity owner	[@name]	[Decision]	YYYY-MM-DD
Product (traffic assumptions)	[@name]	[Decision]	YYYY-MM-DD
Finance / FinOps (cost model)	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	First estimate for design review
0.2	YYYY-MM-DD	[@name]	Example: Peak factor raised from 2 to 3 after reviewing launch traffic of a comparable product
0.3	YYYY-MM-DD	[@name]	Example: Replaced reference throughput with benchmark of the chosen instance type
1.0	YYYY-MM-DD	[@name]	Example: Approved together with the design document

Purpose and scope
Reference numbers
Method
Assumptions register
Formulas
Worked example
Sensitivity analysis
Common pitfalls
Feeding results into design documents
Review checklist
Glossary and references

1. Purpose and scope

1.1 Decisions this estimate informs

ID	Decision	Output that drives it	Threshold that would change the decision
DEC-01	Example: Single relational database or sharded store for metadata	Write QPS, metadata size after 12 months	Above about 5 000 writes/s or 5 TB, consider sharding
DEC-02	Example: Serve images from a CDN or from origin	Peak egress bandwidth	Origin egress above 5 Gbit/s
DEC-03	Example: Size of the application tier for launch	Peak read QPS, per-server capacity	More than 50 instances suggests a different runtime or caching layer
DEC-04	Example: Storage class for originals	Storage growth per year, cost per GB	Storage above 40% of monthly cost
[DEC-nn]	[Decision]	[Output]	[Threshold]

1.2 Scope

In scope: [Example: upload, feed rendering, image serving, metadata storage]
Out of scope: [Example: search indexing, machine learning pipelines, internal analytics]
Horizon: [Example: launch plus 12 months, with a year-3 projection in section 7]

2. Reference numbers

2.1 Latency orders of magnitude

The first two columns reproduce the values shown in Jeff Dean's LADIS 2009 talk. Hardware has moved since then: caches and memory changed little, while solid-state storage and data-centre networks improved by orders of magnitude. Use the "Use for" column to reason about relative cost, and the last column to record what you measured.

Operation	Value in the 2009 list	Order of magnitude	Use for	Your measured value
L1 cache reference	0.5 ns	Nanoseconds	In-process data structures are effectively free	[ ]
Branch mispredict	5 ns	Nanoseconds	Tight loops only	[ ]
L2 cache reference	7 ns	Nanoseconds	Hot working set fits in cache	[ ]
Mutex lock and unlock	25 ns	Tens of ns	Uncontended locks are cheap; contended locks are not	[ ]
Main memory reference	100 ns	Hundreds of ns	Pointer-heavy structures cost memory latency	[ ]
Compress 1 KB with a fast codec (Zippy, now Snappy)	3 µs	Microseconds	Compression before network or disk usually pays	[ ]
Send 2 KB over a 1 Gbit/s network	20 µs	Tens of µs	Serialisation time on the wire	[ ]
Read 1 MB sequentially from memory	250 µs	Hundreds of µs	Scanning in memory is fast but not free	[ ]
Round trip within the same data centre	500 µs	Sub-millisecond	Budget for each remote call on the critical path	[ ]
Disk seek (spinning disk)	10 ms	Milliseconds	Avoid random reads on HDD	[ ]
Read 1 MB sequentially from spinning disk	20 ms	Tens of ms	HDD suits sequential, large reads	[ ]
Packet round trip California to Netherlands	150 ms	Hundreds of ms	Cross-continent calls cannot be on a tight path	[ ]

Two rules follow from the table and still hold: a main memory reference is thousands of times faster than a network round trip, and a cross-continent round trip is a few hundred times slower than a round trip inside one data centre.

2.2 Throughput and bandwidth conversions

Quantity	Conversion
1 Gbit/s	125 MB/s
10 Gbit/s	1.25 GB/s
25 Gbit/s	about 3.1 GB/s
1 MB/s sustained for a day	about 86 GB/day
1 Gbit/s sustained for a 30-day month	324 TB/month
Requests per second to requests per day	multiply by 86 400 (round to $10^{5}$ for a first pass)

2.3 Storage units

Decimal units (powers of ten) are used throughout this worksheet; binary units (KiB, MiB, GiB) differ by about 2.4% at the kilo level and about 10% at the tera level. State which you use.

Decimal	Bytes	Binary	Bytes	Difference
KB	$10^{3}$	KiB	$2^{10} = 1\,024$	2.4%
MB	$10^{6}$	MiB	$2^{20}$	4.9%
GB	$10^{9}$	GiB	$2^{30}$	7.4%
TB	$10^{12}$	TiB	$2^{40}$	10.0%
PB	$10^{15}$	PiB	$2^{50}$	12.6%

Typical sizes to sanity-check inputs: a UUID is 16 bytes in binary form or 36 characters as text; a 64-bit integer is 8 bytes; a short JSON metadata record is usually hundreds of bytes to a few kilobytes.

2.4 Time and availability conversions

Period	Seconds
Minute	60
Hour	3 600
Day	86 400
30-day month	2 592 000
365-day year	31 536 000

Availability	Downtime per 365-day year	Downtime per 30-day month
99%	87.6 h	7.2 h
99.9%	8.76 h	43.2 min
99.95%	4.38 h	21.6 min
99.99%	52.6 min	4.32 min
99.999%	5.26 min	25.9 s

3. Method

Name the decisions the estimate must support (1.1). Stop estimating a quantity once it is clearly on one side of the decision threshold.
Write down the inputs as assumptions with IDs, values, units and sources (section 4). Prefer production data from a comparable feature, then market or product forecasts, then explicit guesses marked as such.
Derive request rates: daily volume, average QPS, then peak QPS using a stated peak factor. Separate reads from writes; they scale differently.
Derive data volumes: bytes per write, daily growth, retention, then storage after replication or erasure coding.
Derive bandwidth: ingress and egress at average and peak, before and after CDN or cache offload.
Size caches from the working set, not from total data.
Size compute from peak load divided by measured per-server capacity at a target utilisation, then add redundancy for the failure you must survive.
Price it with unit costs from your provider's price list or your contract, and show the cost drivers.
Test the sensitivity of the outputs to the most uncertain inputs (section 7) and record which decisions flip.
Publish the summary in the design document, link to this worksheet and schedule a re-check against real traffic after launch.

Round consistently: round inputs to two significant figures, keep full precision through the arithmetic, and round results up for capacity and to the nearest sensible unit for reporting.

4. Assumptions register

ID	Input	Symbol	Value	Unit	Source	Confidence
AS-001 (Example)	Daily active users	$U$	10 000 000	users	Product forecast for month 12	Medium
AS-002 (Example)	Photos viewed per user per day	$v$	50	views/user/day	Comparable app analytics	Medium
AS-003 (Example)	Share of users who upload on a given day	$f$	10%	fraction	Comparable app analytics	Low
AS-004 (Example)	Photos uploaded per uploading user per day	$u$	2	photos/day	Comparable app analytics	Medium
AS-005 (Example)	Peak-to-average ratio	$k_{p}$	3	ratio	Hourly traffic curve of current product	Medium
AS-006 (Example)	Stored size per photo (original 2 MB plus renditions 0.5 MB)	$s_{p}$	2.5	MB	Sample of 1 000 uploads	High
AS-007 (Example)	Upload size sent by the client (original only)	$s_{u}$	2	MB	Sample of 1 000 uploads	High
AS-008 (Example)	Average bytes served per view (feed rendition)	$s_{v}$	200	KB	Rendition specification	High
AS-009 (Example)	Metadata per photo including indexes	$s_{m}$	1	KB	Schema draft	Medium
AS-010 (Example)	Storage overhead factor (erasure coding)	$\rho$	1.5	ratio	Object store documentation	High
AS-011 (Example)	CDN cache hit ratio for images	$h$	90%	fraction	Current CDN reports	Medium
AS-012 (Example)	Hot fraction of daily read items to cache	$c$	20%	fraction	Popularity distribution of current product	Low
AS-013 (Example)	Read capacity of one application server at saturation	$q_{r}$	2 500	req/s	Load test on target instance type	High
AS-014 (Example)	Upload capacity of one upload worker at saturation	$q_{w}$	50	uploads/s	Load test including rendition generation	Medium
AS-015 (Example)	Target utilisation at peak	$\eta$	60%	fraction	SRE policy	High
AS-016 (Example)	Zones, of which one may fail	$z$	3	zones	Deployment standard	High
AS-017 (Example)	Object storage price	$p_{s}$	0.02	USD per GB-month	Provider price list, region [x]	High
AS-018 (Example)	CDN egress price	$p_{e}$	0.01	USD per GB	Contract	Medium
AS-019 (Example)	Compute price per instance	$p_{c}$	150	USD per instance-month	Provider price list	High
[AS-nnn]	[Input]	[Symbol]	[Value]	[Unit]	[Source]	[High / Medium / Low]

5. Formulas

5.1 Request rates

Daily read and write volumes, average QPS and peak QPS:

D_{r} = U \times v, \qquad D_{w} = U \times f \times u

Q_{avg} = \frac{D}{86\,400}, \qquad Q_{peak} = Q_{avg} \times k_{p}

Use a peak factor from your own hourly curve where you have one. Daily traffic with a strong evening peak often shows a peak-to-average ratio of two to three; launches, campaigns and live events can be far higher, so treat them as separate scenarios.

5.2 Storage growth

Daily growth, growth over the planning horizon $T$ days, and raw storage after the redundancy overhead $\rho$ :

G_{day} = D_{w} \times s_{p}, \qquad S_{T} = G_{day} \times T, \qquad S_{raw} = S_{T} \times \rho

If retention is shorter than the horizon, storage plateaus at $G_{day} \times \text{retention days}$ . Add metadata separately: it is small but sits on more expensive storage.

5.3 Bandwidth

B_{egress} = Q \times s_{v}, \qquad B_{ingress} = Q_{w} \times s_{u}, \qquad B_{origin} = B_{egress} \times (1 - h)

Convert bytes per second to bits per second by multiplying by 8 before you compare with network links.

5.4 Cache size

A first-pass upper bound treats every read in a day as a distinct item and caches the hot fraction $c$ :

C = D_{r} \times c \times s_{item}

This overstates the need when reads repeat, which they usually do; refine it with the number of distinct items read per day when you have it.

5.5 Servers needed

Divide peak load by usable per-server capacity, round up, then add capacity to survive the loss of one of $z$ zones:

N = \left\lceil \frac{Q_{peak}}{q \times \eta} \right\rceil, \qquad N_{zone} = \left\lceil N \times \frac{z}{z - 1} \right\rceil

5.6 Cost

\text{Cost}_{month} = S_{raw} \times p_{s} + E_{month} \times p_{e} + N_{total} \times p_{c}

where $E_{month}$ is the monthly egress volume in GB. Include support, licences, data transfer between zones and regions, and operational staff in the total cost model of the design document; this formula covers only the variable infrastructure drivers.

6. Worked example

The example sizes a photo sharing service at month 12 using the Example assumptions AS-001 to AS-019. All values are illustrative.

6.1 Request rates

D_{r} = 10^{7} \times 50 = 5 \times 10^{8} \ \text{views/day}, \qquad D_{w} = 10^{7} \times 0.1 \times 2 = 2 \times 10^{6} \ \text{uploads/day}

Q_{r,avg} = \frac{5 \times 10^{8}}{86\,400} \approx 5\,787 \ \text{req/s}, \qquad Q_{r,peak} = 5\,787 \times 3 \approx 17\,361 \ \text{req/s}

Q_{w,avg} = \frac{2 \times 10^{6}}{86\,400} \approx 23.1 \ \text{uploads/s}, \qquad Q_{w,peak} = 23.1 \times 3 \approx 69.4 \ \text{uploads/s}

The read-to-write ratio is 250 to 1, so the read path dominates compute and bandwidth while the write path dominates storage.

6.2 Storage

G_{day} = 2 \times 10^{6} \times 2.5 \ \text{MB} = 5 \ \text{TB/day}, \qquad S_{365} = 5 \times 365 = 1\,825 \ \text{TB}

S_{raw} = 1\,825 \times 1.5 = 2\,737.5 \ \text{TB} \approx 2.74 \ \text{PB after one year}

Metadata grows by $2 \times 10^{6} \times 1 \ \text{KB} = 2$ GB per day, or 730 GB per year: a single replicated relational database holds it, which answers DEC-01 for the first year.

6.3 Bandwidth

B_{egress,avg} = 5\,787 \times 200 \ \text{KB} \approx 1.16 \ \text{GB/s} \approx 9.3 \ \text{Gbit/s}

B_{egress,peak} = 17\,361 \times 200 \ \text{KB} \approx 3.47 \ \text{GB/s} \approx 27.8 \ \text{Gbit/s}

B_{origin,peak} = 27.8 \times (1 - 0.9) \approx 2.8 \ \text{Gbit/s}

B_{ingress,peak} = 69.4 \times 2 \ \text{MB} \approx 139 \ \text{MB/s} \approx 1.1 \ \text{Gbit/s}

Peak egress of 27.8 Gbit/s needs a CDN; with a 90% hit ratio the origin serves about 2.8 Gbit/s, below the DEC-02 threshold.

6.4 Cache

Caching rendered metadata for the hot fraction of the day's views:

C = 5 \times 10^{8} \times 0.2 \times 1 \ \text{KB} = 100 \ \text{GB}

This upper bound fits in a small in-memory cache cluster (for example three nodes with 64 GB of memory each, leaving room for replication and overhead).

6.5 Servers

Read tier, usable capacity $2\,500 \times 0.6 = 1\,500$ req/s per server:

N_{r} = \left\lceil \frac{17\,361}{1\,500} \right\rceil = \lceil 11.6 \rceil = 12, \qquad N_{r,zone} = \left\lceil 12 \times \frac{3}{2} \right\rceil = 18

Upload tier, usable capacity $50 \times 0.6 = 30$ uploads/s per worker:

N_{w} = \left\lceil \frac{69.4}{30} \right\rceil = \lceil 2.3 \rceil = 3, \qquad N_{w,zone} = \left\lceil 3 \times \frac{3}{2} \right\rceil = \lceil 4.5 \rceil = 5

Total compute: 23 instances, well below the DEC-03 threshold.

6.6 Monthly egress volume

E_{day} = 5 \times 10^{8} \times 200 \ \text{KB} = 100 \ \text{TB/day}, \qquad E_{month} = 100 \times 30 = 3\,000 \ \text{TB} = 3 \times 10^{6} \ \text{GB}

6.7 Cost at month 12

Driver	Calculation	Monthly cost (USD)
Object storage (Example)	2 737 500 GB x 0.02	54 750
CDN egress (Example)	3 000 000 GB x 0.01	30 000
Compute (Example)	23 instances x 150	3 450
Total variable infrastructure		88 200

Storage is 62% of the variable cost and keeps growing every month, which crosses the DEC-04 threshold: a lifecycle rule that moves originals older than 90 days to an infrequent-access class is worth designing now.

6.8 Summary

Quantity	Average	Peak	Design consequence
Read QPS	5 787	17 361	Stateless read tier, 18 instances across 3 zones
Upload QPS	23.1	69.4	Asynchronous rendition workers, 5 instances
Storage after 12 months	1 825 TB logical	2.74 PB raw	Object storage with lifecycle tiers
Metadata after 12 months	730 GB		Single replicated relational database
Egress	9.3 Gbit/s	27.8 Gbit/s	CDN mandatory; origin peak about 2.8 Gbit/s
Cache		100 GB	Three-node in-memory cache
Monthly variable cost		USD 88 200	Storage is the main driver

7. Sensitivity analysis

7.1 One-at-a-time variation

Scenario	Changed input	Output affected	Baseline	New value	Decision flipped?
SEN-01 (Example)	Peak factor 3 to 5 (AS-005)	Read servers with zone redundancy	18	$\lceil 28\,935 / 1\,500 \rceil = 20$ , then 30	No (DEC-03 still below 50)
SEN-02 (Example)	CDN hit ratio 90% to 80% (AS-011)	Origin peak egress	2.8 Gbit/s	5.6 Gbit/s	Yes: DEC-02 threshold exceeded, add an origin shield
SEN-03 (Example)	Daily users doubled (AS-001)	Raw storage after one year	2.74 PB	5.48 PB	No, but storage cost doubles to USD 109 500 per month
SEN-04 (Example)	Stored size per photo 2.5 MB to 4 MB (AS-006)	Raw storage after one year	2.74 PB	$2 \times 10^{6} \times 4 \ \text{MB} \times 365 \times 1.5 = 4.38$ PB	No
SEN-05 (Example)	Upload share 10% to 20% (AS-003)	Upload workers with zone redundancy	5	$\lceil 138.9 / 30 \rceil = 5$ , then 8	No
[SEN-nn]	[Input change]	[Output]	[Baseline]	[New]	[Yes / No]

7.2 Growth projection

Horizon	Daily users	Raw storage (cumulative)	Peak read QPS	Note
Month 12 (Example)	10 million	2.74 PB	17 361	Baseline
Month 24 (Example)	15 million	2.74 + 4.11 = 6.85 PB	26 042	Storage grows faster than traffic because nothing is deleted
Month 36 (Example)	20 million	6.85 + 5.48 = 12.33 PB	34 722	Revisit retention and lifecycle policy

Year-2 storage added is $1.5 \times 10^{7}$ users times the same per-user rates: $1.5 \times 10^{7} \times 0.1 \times 2 \times 2.5 \ \text{MB} \times 365 \times 1.5 \approx 4.11$ PB; year 3 at $2 \times 10^{7}$ users adds about 5.48 PB. The projection assumes users reach the stated count at the start of each year, which is conservative for storage.

7.3 Scenarios outside the model

List events the formula does not capture and how the design handles them:

[Example: a viral post that sends 10 times normal traffic to one image: handled by the CDN, not by origin capacity]
[Example: a marketing launch in a new region: separate estimate with its own peak factor]
[Example: a backfill job that re-renders all photos: scheduled off-peak with its own worker pool]

8. Common pitfalls

ID	Pitfall	Consequence	Prevention
PIT-01	Using average load to size capacity	Saturation every evening peak	Always size from peak, with a stated peak factor
PIT-02	Mixing decimal and binary units	Errors of 5 to 12% at large scales	State the unit convention once and keep it
PIT-03	Forgetting replication, erasure coding, indexes or compaction space	Storage under-provisioned by 1.5 to 3 times	Apply an explicit overhead factor per store
PIT-04	Bits and bytes confused	Bandwidth wrong by a factor of 8	Write the unit on every bandwidth number
PIT-05	Sizing to 100% utilisation	No headroom for spikes, garbage collection or failover	Divide by a target utilisation and add zone redundancy
PIT-06	Using reference latencies as facts	Designs tuned to 2009 hardware	Benchmark the chosen instance type and network
PIT-07	Ignoring fan-out	One user request becomes many backend calls	Multiply by the fan-out of each request type
PIT-08	Ignoring retries and background work	Real load exceeds user-driven load	Add retry amplification, batch jobs and replication traffic
PIT-09	False precision	Reviewers trust five-digit numbers built on guesses	Round results and keep confidence labels
PIT-10	Estimate never revisited	Capacity plan drifts from reality	Schedule a check against production at 30 and 90 days

9. Feeding results into design documents

9.1 Traceability matrix

Estimate	Value	Assumptions	Consumed by	Section	Decision recorded
Peak read QPS (Example)	17 361 req/s	AS-001, AS-002, AS-005	System design document (`system-design/system-design-document`)	3, 8	Read tier size and autoscaling floor
Raw storage after one year (Example)	2.74 PB	AS-001, AS-003, AS-004, AS-006, AS-010	Database design (`architecture/database-design`)	Storage	Object store with lifecycle tiers
Origin peak egress (Example)	2.8 Gbit/s	AS-008, AS-011	Infrastructure design (`architecture/infrastructure-design`)	Network	CDN with origin shield
Monthly variable cost (Example)	USD 88 200	AS-017 to AS-019	TCO analysis (`architecture/tco-analysis`)	Run costs	Budget request
Instances per zone (Example)	6 read, 2 upload (rounded up)	AS-013 to AS-016	Capacity plan (`ops/capacity-plan`)	Headroom	Launch capacity and review dates
[Estimate]	[Value]	[AS-nnn]	[Document]	[Section]	[Decision]

9.2 How to present the estimate

Put the summary table (6.8) in section 3 of the design document and link to this worksheet for the derivation.
State the two or three assumptions that matter most and their confidence.
Show the sensitivity result that flips a decision and the mitigation.
Record the date the estimate was made and the date it will be compared with production telemetry.
Use the system design templates in this collection, such as the rate limiter (system-design/design-rate-limiter), news feed (system-design/design-news-feed), URL shortener (system-design/design-url-shortener), distributed key-value store (system-design/design-distributed-kv-store) and message queue (system-design/design-message-queue), as models of how an estimate is turned into component choices.

9.3 After launch

Check	When	Compared with	Action if off by more than 30%
Peak QPS	Day 30	Section 6.1	Update AS-005 and re-run section 6.5
Storage growth	Day 30 and day 90	Section 6.2	Update AS-006 and the lifecycle policy
CDN hit ratio	Day 30	AS-011	Review cache keys and TTLs
Cost	First two invoices	Section 6.7	Feed into FinOps review

10. Review checklist

11. Glossary and references

11.1 Glossary

Term	Meaning
QPS	Queries or requests per second
Peak factor	Ratio of the busiest interval's rate to the daily average rate
Working set	Data accessed often enough in a period that caching it pays
Erasure coding	Redundancy scheme that stores parity fragments instead of full copies; overhead below plain replication
Target utilisation	Highest planned use of a resource at peak, leaving headroom
Zone redundancy	Extra capacity so that losing one availability zone does not overload the rest
Significant figure	Digit that carries meaning in a rounded number

11.2 References

Reference	Use
Jeff Dean, "Designs, Lessons and Advice from Building Large Distributed Systems", LADIS 2009 keynote (slide "Numbers everyone should know")	Latency orders of magnitude in 2.1
Jeff Dean, "Software Engineering Advice from Building Large-Scale Distributed Systems", lecture slides (copy hosted at cs.princeton.edu, COS 518 reading list)	Same list and the practice of estimating on the back of an envelope
Your cloud provider's instance and storage documentation	Replacement values for 2.1 and 2.2
Your provider's price list or contract	Unit costs AS-017 to AS-019
Capacity plan (`ops/capacity-plan`)	Ongoing capacity management after launch

Standard and licence note

Based on common engineering practice for back-of-the-envelope estimation and on the latency figures publicly presented by Jeff Dean in 2009, reproduced here as short factual values with attribution and labelled as orders of magnitude that change with hardware. The method, formulas, worked example and guidance are original text written for this collection; all numbers in the example are illustrative. Check current hardware benchmarks and your provider's current prices before relying on any figure. Template licence: MIT.

Modèles associés

Conception système