Fixed and variable costs: specify the decision horizon

A resource already committed for this week can be fixed for a decision about one additional request, while the same resource is avoidable in a decision about next quarter. An operator salary, a minimum service fee, and a reserved allocation have different cancellation and renewal boundaries. Record the horizon and the alternative action before classifying them. A charge may also be sunk for the current decision: allocating it to teams can help accountability without making it recoverable when their workload disappears.

Shared services add a second distinction between causal cost and an allocation convention. A team can receive ten percent of an observability pool because it has ten percent of an agreed usage weight. Removing that team need not reduce the pool bill by ten percent if capacity remains provisioned. Conversely, a small load reduction can cross a capacity step and avoid an entire replica. Publish the allocation policy separately from the engineering prediction of what changes under the proposed action; both can be useful without being the same number.

Average cost distributes the whole chosen numerator across the selected denominator. It can support chargeback or comparison of complete deployments, provided failures and shared overhead are handled consistently. Incremental cost asks what additional spending the decision causes. In the local linear model that increment is the variable rate times extra work, while the fixed term remains. Do not multiply an average including fixed overhead by added requests and call the result an avoidable marginal bill; that charges the same fixed pool again.

A constant variable rate is itself an approximation. An extra workload can require another replica, a larger database tier, more checkpoint storage, or an additional network path. It can also alter cache reuse, batching, and incident burden. Describe a piecewise model or explicitly mark the operating range instead of extrapolating one slope indefinitely. Account for setup and shutdown costs when changing configurations, and include capacity or latency constraints that make a mathematically cheap operating point infeasible for the required service.

Build the comparison from resource lifetimes, operation counts, and shared pools, then state which terms actually change. A faster kernel may reduce an allocated-time charge, improve latency while leaving a committed pool unchanged, or create room for more traffic without reducing this period’s spending. These are distinct outcomes. Reconcile the predicted change with the accounting boundary and evaluate the whole service. A smaller average cost achieved by dropping difficult requests is not a valid efficiency improvement under a fixed successful-work requirement.

The function lab illustrates a warning about nonconstant marginal change. Reset, explicitly set a=0.5 and x=1, predict the slope, then Play or Step. In a separate fresh Reset set a=0.5 and x=2; slopes are one and two. This quadratic toy is deliberately different from our linear cost model: its changing derivative shows why a locally estimated slope need not transfer to another operating point. It contains no cost ledger, capacity step, procurement policy, or service-quality constraint. Use actual measurements to decide whether a real variable rate remains approximately constant.