In November 2024, Jake Paul, a YouTuber turned boxer, stepped into the ring with Mike Tyson, a fifty-eight-year-old former heavyweight champion, and Netflix, which streamed the bout, would later report a peak of 65 million concurrent streams, a record by any measure, and an embarrassment by at least one, since a good many of those viewers spent the evening watching not a boxing match but a buffering wheel. The irony would be funnier if it weren’t so expensive. Netflix is hardly short of hardware; it runs a delivery network of its own design, with thousands of purpose-built servers tucked inside internet providers’ networks around the world. If one of the best-equipped streamers on the planet cannot buy its way out of buffering, what hope is there for anyone else?

Adding hardware makes sense, at one level; more servers, more room, fewer jams, or so the logic goes. The fallacy lies in how the internet actually moves its traffic. Its routing protocol, the Border Gateway Protocol, effectively sends all of it over the same shortest route, i.e. through the same routers, with the single-mindedness of a commuter who refuses to try the side streets. Capacity built anywhere else sits idle: a sad sight, and a costly one.

Consider what it would take to double the internet’s capacity with hardware alone. You would be rebuilding the internet, router by router, and once the last one was bolted into place, the routing protocol would go right on funneling traffic down the same path. Software, then, is the only viable way out, specifically transportation optimization, which puts to work the capacity we have already paid for.

Then there is the matter of blame, which tends to end up with the content delivery network almost by default. A stream, though, travels three stretches: the first mile, out of the source; the last mile, into your living room; and, coiled between them, the middle mile, a patchwork of networks run by carriers who are part partners, part rivals. That middle stretch is where most congestion and latency are created. As we have noted at System73, congestion tends to pile up in that critical middle mile whenever a live event sends demand spiking—precisely the moment a broadcaster can least afford it. 

Content providers can watch their servers and they can watch their viewers, but what happens in between is a blind spot, and so the CDN, the most visible link in the chain, takes the blame for congestion it never created. System73 was designed to give providers sight of that middle mile, for the simple reason that you cannot route around a problem you cannot see.

Misdiagnose the problem and you acquire an expensive habit of adding more CDNs, each of which helps a little less than the last, since every one of them still squeezes its traffic through the same congested middle mile. In other words, the returns diminish, and fairly quickly. Worse, hardware carries a limit that no budget can lift. Every new viewer is one more claim on a fixed set of servers, so the bigger the audience, the heavier the strain.

Software can turn that arithmetic on its head. At System73, viewers’ devices are transformed into nodes and linked into centrally orchestrated delivery trees, so that every person who tunes in also lends capacity, and the network grows stronger as demand rises. We saw it this summer, when we helped broadcasters across Latin America stream the 2026 World Cup: at peak demand, up to 83% of Brazilian broadcaster SBT’s traffic traveled between viewers rather than through the CDN, giving it up to five times the delivery capacity of a CDN-only setup. Why keep paying for servers that buckle as an audience grows, when the audience itself can become the network?

We will not build our way out of congestion. The capacity is, for the most part, already in place, and the tools to use it tremendously more efficiently already exist. In my view, the internet already has the road space, what it lacks is a better map.