Range-aware, slice-based
Objects are cached in slices, so a mid-film seek is served from disk rather than becoming an origin fetch of everything before it.
A general-purpose cache treats a 4 GB film like a large web page. Video is not that: viewers seek, they abandon, they resume three days later, and every one of those behaviours is a range request the cache has to be clever about.
Delivery is the largest recurring cost in streaming and the one where paying more buys the least differentiation. That combination is exactly what makes it worth owning: it is expensive, and nobody is going to out-innovate you at moving a byte.
What is worth engineering is the cache behaviour. A viewer who drags the scrubber to the ninety-minute mark generates a range request in the middle of a large object. A cache designed for web assets either fetches the whole object or misses; an edge designed for video serves that range from disk and never troubles the origin.
Objects are cached in slices, so a mid-film seek is served from disk rather than becoming an origin fetch of everything before it.
The token is re-checked on every segment rather than once when playback starts. Copying a manifest URL does not copy access to the film.
HTTP/3 matters most on exactly the connections that suffer most — mobile networks with loss, where head-of-line blocking is the difference between a rebuffer and a shrug.
Requests are answered from the node closest to the viewer in network terms, which is not always the one closest on a map.
| Concern | Generic CDN default | This edge |
|---|---|---|
| Mid-object seek | Full-object fetch or miss | Slice served from cache |
| Authorisation | Signed URL checked once | Token checked every segment |
| Live vs VOD | Shared cache and policy | Separate edges, separate policies |
| Transport | HTTP/2, sometimes HTTP/3 | HTTP/2 and HTTP/3, tuned for segments |
| Billing | Per gigabyte delivered | Bandwidth commit on owned capacity |
| Telemetry | Aggregated, delayed | Per-session, continuous, in your estate |
Most streaming architecture is argued at the top of the ladder — 4K, HDR, the bitrate a flagship phone on fibre can pull. For a service whose audience is outside a capital city, the number that decides whether people watch is at the other end, and it is rarely discussed.
An adaptive ladder is only as useful as its lowest rung. A ladder that starts at 720p has nothing to offer a connection that cannot hold 720p, so the player buffers, drops the session, and the viewer concludes the service does not work — which is a product failure that looks like a network failure. A ladder with a genuine low rung steps down instead, and the picture gets softer rather than stopping.
The step-down has to happen before the buffer empties rather than after, because a viewer forgives a quality change and does not forgive a spinner. That is a tuning decision in the ladder and in the player, not a property of the codec, and it is one of the things worth measuring against your own audience rather than accepting a default for.
Distance matters as much as bandwidth. A connection with room for 2 Mbps still stalls if every segment crosses a transit link to another continent, because the round trip decides how fast the player can react to its own measurements. An edge peered inside the country turns a marginal connection into a usable one without changing the ladder at all, which is the argument for in-country delivery stated in the only terms that matter to a viewer.
Yes, and that is often the right first step — serve the baseline from your own edge and let the commercial CDN absorb overflow and distant traffic.
It follows your audience distribution and your peering, not a formula. Sizing is one of the outputs of discovery.
Health checks pull it out and traffic moves to a peer or to origin, degraded but serving. That path is tested rather than assumed.
Including the origin egress feeding your CDN. Most teams have never calculated the combined figure, and it is usually the number that decides the architecture.