How do you build a cost-per-request model for a proposed architecture before writing code, and which cost terms are most often omitted?

Why this belongs in the design review

A cost-per-request figure is calculable from a design document, and it is the number that most reliably changes an architectural decision. Teams routinely commit to a structure whose recurring cost they have never estimated and discover it in an invoice, at which point the structure is entrenched and the fix is a rewrite.

The Prime Video video-quality monitoring case is the canonical demonstration: orchestration billed per state transition, with the unit of work being a video frame rather than a stream, plus intermediate data crossing object storage at every step. Both terms were derivable from the design; neither was compute.

Building the model

For one representative request, enumerate:

1. Compute time × unit price, per service in the path — including the services the request fans out to.
2. Number of network hops, and for each: bytes transferred and whether the transfer crosses a billed boundary (cross-zone, cross-region, internet egress).
3. Storage operations: reads, writes, and the per-operation price, which for object storage is often more significant than the bytes.
4. Orchestration and coordination: state transitions, queue operations, lock acquisitions — priced per operation, and the operation count is set by the unit of work, which may be far finer than the request.
5. Database operations, in provisioned capacity units or per-query cost.
6. Third-party API calls, each with its own price.
7. The telemetry the request generates — logs, metrics, spans — which is a real and frequently omitted line item that can rival the compute cost.

Multiply by request volume, and by the ratio between average and peak if capacity is provisioned for peak.

The terms most often omitted

• Data transfer between availability zones, which is billed and which a multi-AZ design incurs on a large fraction of internal calls.
• Per-operation storage pricing, where a workload doing many small object reads pays far more for the requests than for the bytes.
• Intermediate data written and immediately read — the most expensive form of coupling, and the one that looks free on a diagram.
• Orchestration priced per transition, whose count scales with the granularity of decomposition.
• Telemetry cost, which grows with request volume and with the number of services in the path.
• Idle capacity, since provisioned resources are paid for continuously and the per-request cost must divide the total by actual rather than peak volume.
• Retries, which multiply every downstream term by the retry rate.
• The cost of the failure path, which for a system with a high error rate can be material.

What the model is actually for

Not precision. The model is for finding the term that dominates, which is frequently a surprise and is frequently something other than compute. Once identified, the architectural question becomes specific: can the boundary that generates this cost be moved, batched, or removed?

The second use is sensitivity analysis: at 10× volume, which term grows fastest? A design whose dominant cost scales super-linearly with volume is a design with an expiry date, and knowing that at design time is worth far more than an accurate absolute figure.