A video catalogue is being modelled for a content delivery contract. Akamai's own documentation calls the share of requests served from its edge rather than from your origin "origin offload". Delivered volume is 400 TB a month and four levers are proposed. Which should the cost model say to do first?
Show the full answer Hide the answer
The deciding property
Two meters are in play and they are not priced alike. Cloud egress from your origin is typically an order of magnitude dearer per gigabyte than committed delivery capacity, so the bill is dominated by the small fraction of traffic that misses the edge, not by the large fraction that hits it.
Put numbers on it. At 90% offload, 10% of 400 TB leaves your origin: 40 TB a month at cloud list egress rates. Take offload to 99% and that becomes 4 TB. A nine-point move in a ratio produced a tenfold cut in the expensive meter, while the delivery meter did not move at all.
Why this one first
It is the only lever whose payoff is multiplicative rather than additive, and it needs no contract change and no user-visible change. Its mechanisms are specific: longer cache lifetimes with revalidation, a mid-tier or shield layer so edge misses collapse onto one upstream request rather than hundreds, and request collapsing for the same object. Measure the offload ratio first; if nobody can state it to the nearest percent, the cost model is not finished.
Why the other options fail
- Negotiate the per-gigabyte rate. Worth doing, and it moves the cheaper of the two meters. It also commits volume you must then deliver, and it does nothing about origin egress. This becomes the right first move once offload is above about 99% and delivered bytes genuinely dominate.
- Re-encode to a lower ladder. A real lever that cuts both meters proportionally, but it is bounded by what viewers accept, costs transcode compute to apply to a back catalogue, and changes the product. It wins when the ladder is over-specified for the actual device mix, which is a measurement you can make.
- Cheaper origin storage class. Storage is not the dominant line here, and colder classes add retrieval charges and minimum storage durations, which makes every edge miss more expensive. This option is actively harmful.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Offload already above 99% | Rate negotiation | The expensive meter is already small |
| Long-tail catalogue with a low hit rate | Shielding and tiered distribution | Misses are structural rather than configuration |
| Live rather than on-demand | Request collapsing | Cache lifetime cannot help content that does not exist yet |
| Delivery contract already at a floor rate | Bitrate ladder | Bytes are the only remaining term |
When this is the wrong answer
For a site delivering 50 GB a month, all four options are a waste of an engineer's week. Use whatever delivery the cloud provider bundles and spend the attention elsewhere. This analysis earns its keep when delivery is a top-three line item, which in practice means tens of terabytes a month and up. It also does not apply to content that is personalised per request, where the ceiling on offload is set by cacheability rather than by configuration.