Egress-First Cost Modelling

Engineering attention flows naturally to compute, because that is where the code is. For a video-heavy or media-heavy consumer platform, the cost order is usually egress and bandwidth first, storage second, compute third — so the most satisfying optimisations move the bill least.

The practice is simply to establish the order before choosing what to optimise, which is a day of work and routinely skipped.

Why it matters

A team can spend a quarter making application code faster and reduce total cost by a percentage point, while a week of work on cache hit ratio reduces it by a fifth. The difference is not skill; it is having looked at the bill by category first.

Implementation patterns

Once bandwidth is identified as dominant, the highest-leverage levers are known:

• CDN cache hit ratio. Every point is a direct reduction in origin egress. Improved by consistent URL construction — query-string variation is a common silent cache-buster — longer TTLs on immutable content, origin shielding so a miss in twenty locations produces one origin request, and request collapsing.
• The encoding ladder. Serving a bitrate above what the device can display is pure waste, and the number of renditions multiplies both storage and transcoding cost. Fewer, better-chosen renditions usually beats more.
• Storage tiering by access pattern, since content popularity follows an extreme curve and the long tail belongs on cold storage.
• Committed-use pricing on the predictable baseline — a commercial change with no engineering risk that is routinely left on the table.
• Serving statically wherever possible, since a pre-rendered page on a CDN costs a rounding error compared to a dynamically rendered one.

Industry example

Education platforms such as Physics Wallah and Unacademy serve very large volumes of video to a price-sensitive audience, which makes margin an architectural constraint rather than a finance concern. Encoding ladder choices, segment length and cache hit ratio become design decisions with direct margin consequences — a five-point improvement in cache hit rate is worth more than most application optimisations.

The same inversion applies to media platforms, social feeds, and any product whose payload is large relative to its computation.

Failure scenarios

• Optimising compute in a bandwidth-dominated system, producing effort with no financial effect.
• Cache-busting URLs from query-string variation, session identifiers or inconsistent construction, silently destroying hit rate.
• A rendition ladder that grew by accretion, with renditions nobody requests still being generated and stored.
• Autoscaling an oversized instance type, which scales the waste. Right-size before autoscaling.
• Tracking total spend rather than unit cost, so growth masks efficiency work and nobody can tell whether it is working.

Trade-offs

Aggressive caching means staleness, and long TTLs on content that occasionally changes require a versioned-URL discipline that must be enforced everywhere. Fewer renditions means some devices get a worse experience than they could have. Cold storage means slow retrieval for the long tail.

Each of those is a product decision with a cost attached, and the value of establishing the cost order first is that the conversation happens where the money is rather than where the code is.

Interview question

"Your cloud bill doubled while usage grew 40%. Where do you look first, in what order, and what unit metric would you put on the engineering dashboard so this is visible next time?"