Use rough orders of magnitude to find the limiting resource before coding. Bias to useful bounds, not faux precision.
-
Name the path - turn the request into one concrete operation: request, job, sync, import, query, deploy, render, or checkout.
Done when the hot path is a short ordered list.
-
Attach units - write input assumptions in visible units: RPS, rows, bytes, objects, users, fanout, regions, retries, retention, concurrency.
Done when every variable has a unit and a rough value.
-
Load current numbers - when any estimate depends on hardware, network, storage, serialization, compression, or cloud cost, read sirupsen/napkin-math, especially its README tables, unless repo-local production measurements are more relevant.
Done when the numbers used are either copied from the repo-local system or traced to the napkin-math reference.
-
Budget each step - estimate latency, throughput, and cost for each step using the numbers below, napkin-math, or repo-local measurements.
Done when each step has an optimistic and pessimistic bound.
-
Find the wall - compare required work against the slowest step or tightest quota.
Done when one bottleneck is named with math, not vibes.
-
Trade one constraint - propose 2-4 changes that move the wall: batch, cache, parallelize, colocate, compress, denormalize, drop durability, precompute, or reduce fanout.
Done when each tradeoff says what improves, what worsens, and what must be measured next.
Round these hard. Prefer powers of ten when unsure.
These are fallback memory anchors. For real estimates, use provider docs, production traces, or sirupsen/napkin-math when a row matters.