From benchmark results to capacity and cost

01 / The customer decision

What does it cost to meet the same promise?

Chapter 10 followed work through an entire pipeline. Here the customer asks: “What will each complete deployment cost to process our forecast demand while staying correct, responsive and available?” An instance price answers only one part of that question. Total cost of ownership (TCO) includes the resources and effort needed to deliver the service over a stated period.

Start with the acceptance contract. For an order dashboard, that might mean correct answers, a 200 ms p99 response time measured at the client, a defined error budget, and bounded backlog at a peak of 1,800 useful requests per second. State the query mix, dataset, durability, recovery target and failure scenario too. A fast answer to a different question is not equivalent capacity.

Sustainable capacity is the correct useful work completed per second while those targets hold over the required duration. It is not the offered rate, the best brief burst or the reciprocal of a browser query time. Include maintenance, compaction, backups and recovery when they matter to the service. A native/server run and a priced deployment establish different inputs from the browser-engine runs in Chapter 2.

Use the companion Sizing and TCO for deeper capacity modelling, scenario analysis and uncertainty. This chapter builds the practical bridge and an exportable model you can take to that discussion.

02 / Worked example

Price a complete service group

A service group here is the smallest complete unit you measured and intend to add. It could be a replicated shard plus its share of worker capacity. Define its boundary before using a rate. In this invented example, a group contains three replicas; both the measured rate and hourly compute price already include all three. Physical storage below includes all billable copies and backups.

Headroom is capacity deliberately left unused for bursts, forecast error or maintenance. A 25% headroom target means using at most 75% of the measured sustainable rate. Divide demand by 0.75; multiplying demand by 1.25 leaves only 20% of the resulting capacity unused.

usable rate per group = measured rate × (1 − headroom fraction)
active groups = round up(peak demand / usable rate per group)
total priced groups = active groups + whole-group failure reserve

Option A provides 675 usable requests per second per group: round up 1,800 / 675 to three active groups, then price four including the spare. Option B provides 1,125: two active groups, three priced. The reserve is sized for the loss of a whole group. If you measured an existing replicated cluster under the required failure and its capacity already covers that scenario, adding the same reserve again would double-count it. Set the additional reserve to zero and record the evidence.

Do not multiply either price by three replicas again. Conversely, a single-node rate cannot simply be copied onto a replicated topology: replication can change writes, network use, latency and failover capacity. Measure the priced topology. This simple model assumes independent groups scale linearly. Shared coordinators, hot partitions and serial pipeline stages can invalidate that assumption.

With the other invented inputs below, A totals 35,088 credits over twelve months and B totals 39,768 credits. This is a worked arithmetic result. If A’s sustainable capacity falls to 600 per group, its required count rises to five and its total becomes 40,920 credits. B then costs less in this model. One uncertain performance input changes the decision.

03 / Planning lab

Find the assumption that matters

Run the starting model before editing. Compare group counts, the full cost breakdown and sensitivity rows. Then lower A’s rate from 900 to 600 and calculate again. Observe the discrete jump in deployment size: cost does not always change smoothly with demand or performance.

Replace the example with your own evidence when available. Capacity provenance identifies a measurement, vendor claim, assumption or illustration. A measurement needs a linked run and its conditions. A vendor claim needs its original scope and an independent test plan. Prices and operating quantities have their own source field; a capacity measurement does not make a price quote factual.

Calculate saves the current valid plan locally. Download JSON to back it up or attach it to the Chapter 12 report. Import accepts this planner’s versioned JSON format; it does not turn Chapter 2 browser timings into server capacity. To use infrastructure evidence, inspect its run record, extract the sustainable verified rate with the service-level checks, and cite the record ID in the capacity evidence field.

04 / Read the evidence

Count useful outcomes and complete costs

Cost per useful result uses correct output delivered within the agreed target. Dividing cost by all attempted requests rewards failed or late work. The tool shows projected incorrect/failed and correct-but-late output separately. Its correctness and on-time fractions are explicit planning inputs; the model cannot infer them from capacity. A deployment can look cheap per result and still fail an acceptance criterion.

Use peak demand for capacity and average offered demand for the volume denominator. Confirm the forecast’s duty cycle: a service running all month at peak is different from a service with ten busy minutes each day. Keep attempted work, correct work and on-time correct work distinct in both the run record and the sales claim.

• Compute: data nodes, replicas, coordinators, workers, connectors, load balancers and recovery capacity.
• Storage: physical copies, indexes, retention, logs, snapshots, backups and temporary space; billable operations and retrieval can have separate charges.
• Network: ingress/egress rules, cross-zone replication, cross-region recovery, retries and connector traffic. A zero line needs an explained inclusion or exclusion.
• Commercial and human costs: licences, support, monitoring, on-call work, upgrades, migration, training and recurring operations. Record which are included in another line.

For a pipeline, price every stage and the glue between them. A sink’s peak rate cannot establish the capacity of object storage → worker → broker → database. Verify the proposed complete deployment under the same arrivals and queries, including backlog, recovery and data checks. Re-run sizing when a faster stage shifts the bottleneck.

The sensitivity table is a controlled “what if,” not a confidence interval or probability forecast. It states which quantities change. Demand-driven retention growth, nonlinear licence tiers and worker scaling need separate scenarios. For a more complete study, export the base plan and one independently justified low/high case for each decision-changing input.

05 / Independent task

Defend the cheaper complete deployment

A customer says, “A costs less per instance, so we should buy A.” Build two plans against the same workload and service contract. Use real server evidence where available; otherwise leave capacity explicitly assumed. Find the demand or capacity boundary where the cheaper option changes. State what you would measure before the customer commits.

1. Write the demand trace, target, time horizon, region and failure scenario before looking at the price total.
2. Define each measured/priced group and identify where replication, headroom and recovery are included.
3. Link performance runs and dated price sources separately. Explain every zero or excluded category.
4. Export the base and a decision-changing scenario. Explain the difference in useful customer outcomes and total cost.

06 / What this establishes

A cost estimate is a chain of claims

The calculator establishes arithmetic consequences of supplied inputs. It does not establish that capacity scales, that failover meets the service contract or that an illustrative price is commercially available. The next chapter assembles the evidence, uncertainty and recommendation into a report another person can challenge and reproduce.

Keep your capacity JSON, underlying native/server run records, topology diagram, quantity calculations, dated quotes and exclusions together. Record price region, price date, currency, horizon, discount commitments and evidence age. The Sizing and TCO companion develops this evidence-led approach further. For cost vocabulary and billing checks, consult the FinOps Framework and the pricing documentation for the actual services you intend to buy.