# 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*.

<!--
Guidance: How to use this template
- Fill section 4 (assumptions) before any formula. Every number in sections
  5 to 7 must trace back to an assumption ID or to a measured benchmark.
- Estimate to one significant figure first, then refine only the numbers
  that change a design decision. Precision beyond that is false comfort.
- Replace the reference numbers in section 2 with measurements from your own
  instance types and network as soon as you have them; keep the source column.
- Copy the summary table (6.8) into section 3 of the system design document
  and link back to this worksheet.
-->

## Document control

<!-- Guidance: An estimate is only as good as the assumptions behind it; record who owns them and when they were last checked. -->

| 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

<!-- Guidance: Record which assumption changed and which outputs moved as a result. -->

| 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 |

## Contents

<!-- Guidance: Keep aligned with the headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Reference numbers](#2-reference-numbers)
3. [Method](#3-method)
4. [Assumptions register](#4-assumptions-register)
5. [Formulas](#5-formulas)
6. [Worked example](#6-worked-example)
7. [Sensitivity analysis](#7-sensitivity-analysis)
8. [Common pitfalls](#8-common-pitfalls)
9. [Feeding results into design documents](#9-feeding-results-into-design-documents)
10. [Review checklist](#10-review-checklist)
11. [Glossary and references](#11-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Say which decisions this estimate must inform. An estimate without a decision attached tends to grow into a spreadsheet nobody reads. -->

### 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

<!-- Guidance: These are orders of magnitude for intuition. They vary by hardware generation, cloud provider, instance type and configuration. Replace with your own benchmarks before you commit money. -->

### 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

<!-- Guidance: Follow the steps in order. Skipping straight to server counts is the most common way to get an estimate that cannot be defended. -->

1. **Name the decisions** the estimate must support (1.1). Stop estimating a
   quantity once it is clearly on one side of the decision threshold.
2. **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.
3. **Derive request rates**: daily volume, average QPS, then peak QPS using a
   stated peak factor. Separate reads from writes; they scale differently.
4. **Derive data volumes**: bytes per write, daily growth, retention, then
   storage after replication or erasure coding.
5. **Derive bandwidth**: ingress and egress at average and peak, before and
   after CDN or cache offload.
6. **Size caches** from the working set, not from total data.
7. **Size compute** from peak load divided by measured per-server capacity at
   a target utilisation, then add redundancy for the failure you must survive.
8. **Price it** with unit costs from your provider's price list or your
   contract, and show the cost drivers.
9. **Test the sensitivity** of the outputs to the most uncertain inputs
   (section 7) and record which decisions flip.
10. **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

<!-- Guidance: One row per input. If a reviewer challenges a number, the source column must answer them. Mark guesses honestly; they are the first rows to test in section 7. -->

| 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

<!-- Guidance: Use the same symbols as the assumptions register. Show the formula before substituting numbers so reviewers can check the logic separately from the arithmetic. -->

### 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

<!-- Guidance: Keep the worked example even if your system differs; it shows reviewers the standard of arithmetic expected. Replace it with your own numbers once section 4 is filled. -->

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

<!-- Guidance: Vary the inputs you are least sure about, one at a time, and record which decisions flip. A decision that flips under a plausible change needs a mitigation or a design that tolerates both outcomes. -->

### 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

<!-- Guidance: Review the estimate against this list before the design review. Most estimate failures are one of these. -->

| 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

<!-- Guidance: An estimate only has value if a design decision cites it. This table is the traceability matrix between this worksheet and the documents that depend on it. -->

### 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 (`architecture/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 (`architecture/design-rate-limiter`), news feed
  (`architecture/design-news-feed`), URL shortener
  (`architecture/design-url-shortener`), distributed key-value store
  (`architecture/design-distributed-kv-store`) and message queue
  (`architecture/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

<!-- Guidance: The reviewer ticks each item or writes why it does not apply. -->

- [ ] Every formula input has an assumption ID with source and confidence.
- [ ] Reads and writes are estimated separately.
- [ ] Peak, not average, drives compute and bandwidth sizing.
- [ ] Storage includes replication or erasure coding, indexes and retention.
- [ ] Bandwidth figures state bits or bytes and are compared with link sizes.
- [ ] Cache size is derived from a working set, and the method is stated.
- [ ] Server counts divide by target utilisation and include zone redundancy.
- [ ] Reference numbers are replaced or confirmed by benchmarks.
- [ ] At least three sensitivity scenarios are recorded with decision impact.
- [ ] The summary is copied into the design document with a link back.
- [ ] A post-launch comparison date is scheduled.

## 11. Glossary and references

<!-- Guidance: Define the terms reviewers outside the team may not know, and list every source of a reference number. -->

### 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.