thinking-fermi-estimation

What this skill does

# Fermi Estimation

## Overview

Fermi estimation, named after physicist Enrico Fermi, is the art of making reasonable estimates for quantities that seem impossible to know without direct measurement. By decomposing a question into factors you can estimate, then multiplying, you often get surprisingly accurate order-of-magnitude results.

**Core Principle:** Break the unknown into known (or estimable) pieces. Even rough estimates combine to reasonable accuracy due to errors canceling out.

## Trigger Card

When you need a number you can't measure or look up, and order-of-magnitude is enough:

1. **Decompose:** Quantity = Factor₁ × Factor₂ × ... × Factorₙ (by component, by rate×time, or by population×fraction).
2. **Estimate each factor** with a range, not a point; use geometric mean for order-of-magnitude; round to one significant figure.
3. **Multiply and sanity-check:** Does the order of magnitude make sense? Would a 10× error change the decision?
4. **Report:** "~X, within 3-5×" — never false precision.

If the number is lookup-able (COUNT(*), pricing page, profile it), do that instead — a made-up estimate where a real value exists is strictly worse.

## When to Use

- Capacity planning ("How much storage will we need?")
- Cost estimation ("What will this infrastructure cost?")
- Market sizing ("How many potential users exist?")
- Feasibility assessment ("Is this even plausible?")
- Sanity checking ("Does this number make sense?")
- Interview questions ("How many piano tuners in Chicago?")
- Quick prioritization ("Is this worth pursuing?")

Decision flow:

```
Need a number you don't have? → Can you measure OR look it up cheaply? → yes → DO THAT (don't Fermi it)
                                                                       ↘ no → Will an order-of-magnitude answer suffice? → yes → FERMI ESTIMATE
                                                                                                                          ↘ no → you need real data, go get it
```

## When NOT to Use

- **The number is cheaply lookup-able or measurable.** Don't Fermi the size of a table you can `COUNT(*)`, the latency you can profile, the file size you can `ls`, the price on a pricing page, or any fact one query/search away. A made-up estimate where a real value is available is strictly worse — it adds error and false confidence. Look it up.
- **You need precision, not order of magnitude.** Fermi gives you "~4 TB, within 3-5x." If the decision turns on 3.8 vs 4.2, estimation can't carry it — get the real number.
- **The factors are correlated or you'd be inventing the base rates.** If the decomposition is just stacked guesses with no anchor, the result is theater. Either find one real anchor or flag the whole thing as a rough guess.
- **The decision is identical across the plausible range.** If "somewhere between 1 GB and 1 TB" doesn't change what you do, skip the estimate and act.

## The Fermi Process

### Step 1: Clarify What You're Estimating

Be precise about the quantity:

```
Vague: "How big is the market?"
Precise: "How many SaaS companies with 50-500 employees in the US
         would pay $1000/month for our product?"
```

### Step 2: Decompose into Estimable Factors

Break into pieces you can estimate:

```
Storage needs for user data:
= (Number of users)
  × (Data per user per day)
  × (Days of retention)
  × (Overhead factor)
```

**Decomposition strategies:**

| Strategy | Example |
|----------|---------|
| By component | Total = Sum of parts |
| By rate × time | Total = Rate × Duration |
| By population × fraction | Target = Base × Percentage |
| By analogy × adjustment | New ≈ Similar × Ratio |

### Step 3: Estimate Each Factor

For each factor, estimate based on:

| Source | Example |
|--------|---------|
| Known data | "We have 10,000 DAU" |
| Industry benchmarks | "Average SaaS churn is 5%" |
| Physical constraints | "A human can make ~50 decisions/day" |
| Logical bounds | "At least 1, at most 1 million" |
| Personal experience | "I've seen systems handle 1000 req/s" |

**When estimating:**
- Use ranges, not point estimates: "10,000 to 50,000"
- Prefer geometric mean for order-of-magnitude: √(10,000 × 50,000) = 22,360
- Round to one significant figure: ~20,000

### Step 4: Combine Factors

Multiply (or add) factors together:

```
Storage = 50,000 users × 10 KB/user/day × 365 days × 1.5 overhead
        = 50,000 × 10,000 × 365 × 1.5 bytes
        = 274 billion bytes
        ≈ 270 GB/year
```

### Step 5: Sanity Check

Verify reasonableness:
- Does the order of magnitude make sense?
- Is it physically possible?
- Does it match any known data points?
- Would a 10x error change the decision?
- **Is any factor actually lookup-able?** If so, replace the estimate with the real value — every measured factor you substitute shrinks the error bars.

### Step 6: State Confidence and Implications

```
Estimate: ~270 GB/year
Confidence: Within 3-5x (80-1,500 GB)
Implication: Standard database tier sufficient; no special infrastructure needed
```

## Fermi Estimation Template

```markdown
# Fermi Estimate: [Question]

## Question (Precise)
[Exactly what we're estimating]

## Decomposition
[Quantity] = [Factor 1] × [Factor 2] × ... × [Factor N]

## Factor Estimates

### Factor 1: [Name]
- Estimate: [Value]
- Source/Reasoning: [Why this number]
- Confidence: High / Medium / Low

### Factor 2: [Name]
- Estimate: [Value]
- Source/Reasoning: [Why this number]
- Confidence: High / Medium / Low

[Continue for all factors...]

## Calculation
[Show the math]

## Result
- Point estimate: [Value]
- Range: [Low] to [High] (representing Xx uncertainty)

## Sanity Check
- Physical plausibility: [Check]
- Comparison to known data: [Check]
- Order of magnitude reasonable: [Check]

## Implications
[What does this estimate mean for the decision?]
```

## Example 1: Data Storage Needs

**Question:** How much storage will our new feature need in Year 1?

```markdown
## Decomposition
Storage = Users × Events/User/Day × Event Size × Days × Replication

## Factor Estimates

### Users (DAU)
- Estimate: 100,000 (current) growing to 200,000 (end of year)
- Average over year: ~150,000
- Confidence: High (we have current data)

### Events per User per Day
- Estimate: 50 events (based on current feature usage patterns)
- Confidence: Medium (new feature might differ)

### Event Size
- Estimate: 500 bytes (JSON with typical payload)
- Confidence: High (we can measure similar events)

### Days in Year
- Estimate: 365
- Confidence: Certain

### Replication Factor
- Estimate: 3x (standard for durability)
- Confidence: High (architectural requirement)

## Calculation
Storage = 150,000 × 50 × 500 × 365 × 3
        = 150,000 × 50 × 500 × 365 × 3
        = 4.1 × 10^12 bytes
        = 4.1 TB

## Result
- Point estimate: ~4 TB
- Range: 1 TB (pessimistic assumptions) to 15 TB (growth beats expectations)

## Sanity Check
- 4 TB for 150K users = ~27 MB/user/year = reasonable
- Similar feature at other company uses "several TB" = consistent
- Standard database can handle 4 TB = feasible

## Implications
- Standard managed database tier sufficient
- No need for sharding or special storage architecture in Year 1
- Budget ~$500/month for storage costs
```

## Example 2: API Rate Capacity

**Question:** Can our API handle Black Friday traffic?

```markdown
## Decomposition
Required RPS = Peak Daily Users × Requests/User/Session × Sessions/Day × Peak Multiplier / Seconds in Peak Hour

## Factor Estimates

### Peak Daily Users
- Estimate: 500,000 (3x normal 170K)
- Source: Last year's Black Friday
- Confidence: Medium

### Requests per Session
- Estimate: 30 API calls (measured)
- Confidence: High

### Sessions per Day
- Estimate: 2 (mobile + desktop)
- Confidence: Medium

### Peak Multiplier
- Estimate: 5x (traffic concentrated in 4-hour window, spiky within that)
- Confidence: Medium

### Seconds in Peak Hour
- Estimate: 3,600
- Confidence: Certain

## Calculation
Required RPS = (500,000 × 30 × 2 × 5) / 3