Skip to content
About
Main content

The exchange rate between all the other units

What is actually metered in a price, and why does cost have no failure detector?

Everything before this mechanism in a systems course is measured in units that do not convert: nanoseconds, bytes, IOPS (I/O operations per second), round trips, isolation levels, recovery-point objectives (how much recent data you can afford to lose in a failure). You cannot trade p99 (the time within which 99% of requests finish) against durability without an exchange rate. Money is that exchange rate. This mechanism adds no new mechanisms. It makes the mechanisms you already know comparable to each other for the first time.

What changes. Until now, a design failed because it could not work. Here, designs that work perfectly can still be wrong. "Optimal" stops being a property of a system. It becomes a property of a system plus a price list. A price list is not a law of physics. It is a published function chosen by a vendor. It is piecewise-constant (it jumps at thresholds), and it contains rounding rules and minimum increments that have no physical counterpart. It is only loosely proportional to the real resource cost. Parts of it are profit margin, and parts are deliberate distortion designed to shape your architecture.

What stops mattering. Whether something is technically avoidable. is the clearest case. Nothing in physics says you must pay for a machine you are not using. The pricing model says so, and the design consequences are as real as if it were physics.

The governing question is not "what does this cost?" It is:

Every price has the same form:

the metered quantity
the increment you are charged in
the price per unit
Data table
Billed ÷ used, by job length (60-second minimum increment)
Job length (seconds)Billed ÷ used
160×
1.0855.4×
1.1751.1×
1.2747.2×
1.3843.6×
1.4940.2×
1.6237.1×
1.7534.3×
1.931.6×
2.0529.2×
2.2227×
2.4124.9×
2.6123×
2.8321.2×
3.0619.6×
3.3218.1×
3.5916.7×
3.8915.4×
4.2214.2×
4.5713.1×
4.9512.1×
5.3611.2×
5.8110.3×
6.299.54×
6.818.8×
7.388.13×
87.5×
8.666.93×
9.386.39×
10.25.9×
115.45×
11.95.03×
12.94.64×
144.29×
15.23.96×
16.43.65×
17.83.37×
19.33.11×
20.92.87×
22.62.65×
24.52.45×
26.52.26×
28.72.09×
31.11.93×
33.71.78×
36.51.64×
39.61.52×
42.91.4×
46.41.29×
50.31.19×
54.51.1×
591.02×
63.91.88×
69.31.73×
751.6×
81.31.48×
881.36×
95.41.26×
1031.16×
1121.07×
1211.48×
1311.37×
1421.27×
1541.17×
1671.08×
1811.33×
1961.23×
2121.13×
2301.04×
2491.2×
2701.11×
2921.03×
3161.14×
3431.05×
3711.13×
4021.04×
4361.1×
4721.02×
5111.06×
5541.08×
6001×

where q is the metered quantity, g is the (the increment) and r is the rate. ceil means "round up to the next whole number". Example: a service bills per 60-second increment at $0.0001 per second. A job runs for 5 seconds. q = 5, g = 60, so billed = ceil(5/60) × 60 × 0.0001 = 1 × 60 × 0.0001 = $0.006. The useful work was 5 seconds, but you paid for 60. That is 12× the useful quantity.

It is a proxy that the vendor can observe, attribute to you and defend. The whole discipline lives in the gap between the proxy and the work.

Two honest warnings before the detail.

First: this is the layer with the shortest half-life. The mechanisms (metering, granularity, proxy quantities) are permanent. The rates are contingent. Compute and storage prices fall by roughly 20–30% a year, while network hardly moves. So any design tuned to today's price ratios will age. The ratios are what matter, and the ratios change.

Second: It pages nobody. It breaks no service-level objective (SLO, a latency or availability target). It reports itself through a monthly total. Think about the this creates:

  • the sensor (the invoice) lags the actuator (your design decisions) by about thirty days;
  • the signal is added up past the point where you could say who caused it;
  • the person who can change the system is not the person who reads the invoice.

A loop like that drifts or oscillates. That is the real subject of this mechanism, and it is organizational as much as technical (Control and attribution).