Cost Driver

Every infrastructure cost is a function of some quantity: requests per second, gigabytes stored, events ingested, cross-region bytes transferred, distinct time series, supplier API calls. The cost driver is that quantity, and the useful part of a cost model is the relationship between driver and cost, not the current total.

Knowing the driver tells you what happens at ten times the volume. Knowing the total tells you only what happened last month.

Why identifying it correctly matters

Teams routinely track a metric that correlates with cost today and is not the driver. Cost per order looks stable until the real driver — location updates, inventory synchronisations, search queries per session — grows independently of orders. Then cost per order rises with no change anyone can point at.

The characteristic symptom is a unit metric that behaves well and then stops behaving well, with no corresponding change in the business.

Implementation patterns

• Name the driver as a quantity, not a resource category. "Compute" is not a driver; "recommendation requests per second" is.
• State the scaling relationship for each: linear with users, linear with data, super-linear because of fan-out, fixed regardless of load. This is what makes the model predictive.
• Model a range — low, expected and high — rather than a point, since a single number invites false precision.
• Identify the two or three lines that dominate, and focus the design conversation there rather than distributing attention evenly.
• Run a sensitivity analysis: which assumption, if wrong by a factor of two, changes the answer? That is the most valuable output, because it says what to measure early and what to design to change cheaply.

Industry example

Design-stage cost models fail most often by omitting the dominant term. The lines most frequently missing are cross-region transfer, egress to users, per-request charges on managed services, and observability cost — which for a high-cardinality system can exceed the compute it observes, because cardinality is multiplicative and grows with both traffic and label count.

A second common omission is the cost of not serving: headroom, redundancy, non-production environments and reserved capacity that is idle. These are real, they are frequently a third of the bill, and they appear in no per-request calculation because that calculation divides by successful requests.

The third is operational cost — engineering time to build and run, on-call burden, and the marginal cost of each additional system to operate. A design that is cheaper in infrastructure while adding a new stateful system to operate is frequently more expensive in total, and this is the comparison a purely infrastructure model cannot make.

Failure scenarios

• Tracking a proxy that decouples from the real driver, so the metric looks fine until it does not.
• Modelling one driver when several act together, missing the multiplicative case — session length × candidate pool × feature size is a product with no single owner.
• Estimates never compared against actuals, so the next estimate is no better than the last.
• Precision without accuracy — four significant figures resting on an unexamined traffic assumption.
• A driver nobody monitors, so its growth is discovered on the invoice.

Trade-offs

Modelling drivers properly takes time in a design review that teams would rather spend on the design, and the model will still be wrong in its absolute numbers. Its value is in the relationships and the sensitivity analysis, not the total — and presenting it that way avoids the trap of debating a number that was never going to be right.

Where a workload is small and its cost is a rounding error, the modelling is not worth doing. Where a design decision is hard to reverse and its cost scales super-linearly, it is one of the highest-return hours in the review.

Interview question

"Estimate the monthly cost of a system that ingests a billion events a day and serves ten thousand queries per second over them. Tell me your drivers, which one you are least sure about, and how the design would change if that one is wrong by 10x."