1. Estimation

At 09:55 the BoxOffice team is staring at a dashboard. In five minutes a stadium show goes on sale: 2 million fans for 60 thousand seats. How many requests per second will hit the catalog? How many seat holds per second will the database take? Does the seat map fit in memory? How many app servers do we need? The answers decide the architecture — and you can get them before writing a single line of code, with a sheet of paper and a few formulas. That is what this exercise trains.

Context

Back-of-the-envelope estimation is the second step of the interview framework and the first thing a reviewer looks for in a design doc¹. The goal is the right order of magnitude, not three significant digits: 12 k or 15 k requests per second leads to the same design; 1.2 k or 120 k does not.

The tools come from Class 2 — Estimation: powers of two and ten, the latency and throughput numbers², Little's Law, utilization, percentiles and availability math. In Lab 2 you will check some of these numbers against a real service.

Formulas you will use

Task

Fill in an estimation sheet for five systems:

1. BoxOffice flash sale — mandatory for everybody (facts below).
2. Four systems chosen from the fact sheets below (at least one read-heavy and one write-heavy).

For each system, estimate the quantities in the template, show the arithmetic, and finish with three design consequences derived from your numbers.

BoxOffice facts

• The on-sale of a stadium show starts at 10:00; 2 M fans arrive in the first 10 minutes; there are 60 k seats, at most 4 per order.
• A fan who is browsing does, on average, one request every 3 seconds (catalog, seat map, availability polling).
• A waiting room admits fans to the purchase flow at a rate you must choose so that the sale lasts about 15 minutes.
• A seat hold lasts 5 minutes; about 30% of holds expire without payment.
• An order record is about 1 KB; a ticket e-mail about 50 KB; the seat map of the venue is about 200 KB of JSON.
• Outside on-sales, BoxOffice serves 5 M daily active users browsing ~20 pages each.

Fact sheets

All facts below are illustrative assumptions for the exercise — use them as given and add your own assumptions where needed.

Requirements

• (mandatory) Five complete sheets: BoxOffice + four fact sheets (at least one read-heavy and one write-heavy).
• (mandatory) Every number has a unit and every derived number shows its formula (no bare results).
• (mandatory) Assumptions are listed in a table, separated from the given facts.
• Average and peak QPS, split into reads and writes.
• Storage per year (with replication) and bandwidth (ingress and egress).
• Cache size for the hot set, and whether it fits in one node.
• Number of servers for the hottest path, using Little's Law for concurrency and a target utilization.
• Availability of the main request path (series/parallel) compared with a target SLO.
• One sanity check per system against a reference number (e.g. from the numbers cheat sheet).
• Three design consequences per system, each pointing to a number in the sheet.
• AI usage section (see the policy).

Deliverables

• A page estimation in your documentation site with the five sheets (tag ex1).
• Optional: the spreadsheet or script you used (committed to the repository) — the page must still show the formulas.

Step by step

1. Read the facts and write down the question. "How many seat holds per second at peak?" is a question; "estimate BoxOffice" is not.
2. List assumptions before computing. Write what you assume and why (e.g. "peak factor 3, from a typical daily curve").
3. Compute averages, then peaks. Requests per day ÷ 10⁵ gives the average QPS; multiply by the peak factor. For events (on-sales, campaigns) compute the peak directly from the event: users × request rate.
4. Split reads and writes. They hit different components (cache/CDN vs primary database).
5. Size the data. Items × size × retention × replication. Then the hot set for the cache.
6. Size the compute. Little's Law gives the in-flight requests; capacity per server and a target utilization give the number of servers.
7. Check availability. Multiply the availabilities along the main path; add replicas where the result is below the SLO.
8. Sanity-check. Compare with something you know (a number from class, a public engineering blog, the cheat sheet).
9. Write the consequences. Each consequence is a decision justified by a number.

Worked example: URL shortener

Facts (illustrative): 100 M new short URLs per month; read/write ratio 100:1; records kept 5 years; 500 bytes per record.

Sanity check: 2 MB/s of egress is tiny — a single 1 Gbit/s NIC moves ~125 MB/s. The bottleneck is not bandwidth.

Design consequences:

1. 12 k reads/s vs 120 writes/s → read-heavy: a cache in front of the database (hit ratio above 90% removes most database reads).
2. 9 TB over 5 years → fits one SQL cluster, but a key-value store partitioned by short key keeps growth simple; no join is needed.
3. 99.94% < 99.99% target → the database is the weakest link: add a standby with automatic failover (or accept the SLO).

A tiny helper (optional)

Writing the arithmetic as code keeps units honest. You may adapt this script; the page must still show the formulas.

DAY = 86_400  # seconds


def qps(per_day: float, peak_factor: float = 3.0) -> tuple[float, float]:
    """Average and peak requests per second."""
    avg = per_day / DAY
    return avg, avg * peak_factor


def servers(peak_qps: float, per_server: float, target_util: float = 0.7, spare: int = 2) -> int:
    """Instances needed at the target utilization, plus spare capacity (N+spare)."""
    from math import ceil
    return ceil(peak_qps / (per_server * target_util)) + spare


def series(*avail: float) -> float:
    """Availability of components in series."""
    out = 1.0
    for a in avail:
        out *= a
    return out


def parallel(a: float, n: int) -> float:
    """Availability of n independent replicas."""
    return 1 - (1 - a) ** n


if __name__ == "__main__":
    writes = 100e6 / 30          # URL shortener: writes per day
    w_avg, w_peak = qps(writes)
    r_avg, r_peak = w_avg * 100, w_peak * 100
    print(f"writes {w_avg:,.0f}/s avg, {w_peak:,.0f}/s peak")
    print(f"reads  {r_avg:,.0f}/s avg, {r_peak:,.0f}/s peak")
    print(f"in flight at peak: {r_peak * 0.020:,.0f}")
    print(f"app servers: {servers(r_peak, 1_000)}")
    print(f"availability: {series(0.9999, parallel(0.999, 2), 0.9995):.4%}")

Templates

Copy one sheet per system into your page.

## System: <name>

### Given facts
| Fact | Value |
|-|-|
| ... | ... |

### Assumptions
| # | Assumption | Value | Why |
|-|-|-|-|
| A1 | Peak factor | 3× | daily curve with an evening peak |
| A2 | Capacity per app instance | 1,000 req/s | measured in Lab 2 / cheat sheet |

### Estimates
| Quantity | Formula | Result | Unit |
|-|-|-|-|
| Reads, average | | | req/s |
| Reads, peak | | | req/s |
| Writes, average | | | req/s |
| Writes, peak | | | req/s |
| Storage per year (with replication) | | | TB |
| Ingress bandwidth | | | MB/s |
| Egress bandwidth | | | MB/s |
| Cache (hot set) | | | GB |
| Concurrency at peak (L = λW) | | | requests |
| Servers for the hottest path | | | instances |
| Availability of the main path | | | % |

### Sanity check
<compare one number with a known reference>

### Design consequences
1. <decision> — because <number from the sheet>
2. ...
3. ...

## Sistema: <nome>

### Fatos dados
| Fato | Valor |
|-|-|
| ... | ... |

### Premissas
| # | Premissa | Valor | Por quê |
|-|-|-|-|
| P1 | Fator de pico | 3× | curva diária com pico à noite |
| P2 | Capacidade por instância da aplicação | 1.000 req/s | medido no Lab 2 / cheat sheet |

### Estimativas
| Grandeza | Fórmula | Resultado | Unidade |
|-|-|-|-|
| Leituras, média | | | req/s |
| Leituras, pico | | | req/s |
| Escritas, média | | | req/s |
| Escritas, pico | | | req/s |
| Armazenamento por ano (com replicação) | | | TB |
| Banda de entrada | | | MB/s |
| Banda de saída | | | MB/s |
| Cache (conjunto quente) | | | GB |
| Concorrência no pico (L = λW) | | | requisições |
| Servidores no caminho mais quente | | | instâncias |
| Disponibilidade do caminho principal | | | % |

### Verificação de sanidade
<compare um número com uma referência conhecida>

### Consequências para o design
1. <decisão> — porque <número da planilha>
2. ...
3. ...

Rubric

Levels as defined in How the exercises are graded.

FAQ