Are we re-solving live broadcast - or solving a different problem?

The reason it's not quite fair is that broadcast and streaming are solving different problems that look similar from the user's seat. Broadcast pushes the same content to all receivers simultaneously - a one-to-many problem with brutal but tractable engineering. Streaming pulls customised content per session - a many-to-many addressable problem with very different engineering constraints. The two systems converge on the user experience of 'live video on my screen', but the architectures underneath are categorically different. Streaming engineers re-solving 'live video' aren't re-solving broadcast's problem; they're solving a problem that didn't exist as a category until streaming created it.

Where broadcast still wins

For pure live events with no personalisation - a national broadcast, a major sporting event, a state ceremony - broadcast remains technically and economically superior to streaming. The cost-per-viewer of broadcast for a hundred-million concurrent audience is dramatically lower than streaming's cost. Latency is consistently lower. Reliability under peak load is structurally better, because broadcast doesn't have a per-session resource cost the way streaming does. For these use cases, the streaming industry's complexity is a step backward from a working solution that was built decades ago.

The Doordarshan reference is apt here. India still has hundreds of millions of viewers reachable through broadcast that streaming services cannot economically serve. The digital divide is real. The triumphalism around streaming sometimes ignores the populations broadcast still serves better, and the framing 'broadcast is legacy' is a Silicon Valley perspective that doesn't generalise to most of the world's actual television audience. For the world cup, the Olympics, royal events with massive concurrent audiences, broadcast remains the right answer in 2026.

What streaming actually does that broadcast can't

The genuine wins of streaming are not in 'live video' as a category - they're in the additional capabilities the broadcast architecture couldn't support. Per-user content personalisation. Quality adaptation per network connection. Pause, seek, rewind, on-demand replay. Regional variation at fine granularity. Rights management at the user level. Interactive features. Each of these was either impossible or wildly expensive in the broadcast model. Streaming's complexity is justified when these capabilities are part of the product. It's not justified when the product is just 'show the same video to everyone simultaneously'.

The mistake many streaming products make is using the same architecture for both kinds of problem. A live event with no personalisation gets routed through a streaming infrastructure that's optimised for personalisation, with all the cost and complexity of the latter and none of the benefit. The right answer for that case is closer to a CDN-fronted simulcast than the full streaming stack. Some streaming providers have figured this out and route different problems through different paths. Most haven't, and they pay the cost in either money or reliability.

The general lesson

There's a wider engineering principle in this observation. Engineers often re-solve problems whose elegant solutions exist in older technologies, because the older technologies look obsolete from a modern toolchain perspective. The right question isn't 'have we solved this' - it's 'in our specific constraints, is the older solution still optimal'. Sometimes the older solution is genuinely the best answer. Sometimes the new constraints require new approaches. The discipline is being honest about which case you're in, and the discipline is harder than it sounds because the new tools have more interesting engineering problems and the old tools' engineers have mostly retired.

This shows up in many domains beyond broadcast. Industrial IoT engineers re-implement protocol stacks that the telecoms industry solved decades ago. Database engineers re-solve concurrency problems that mainframe systems handled cleanly in the 1970s. Distributed-systems folks re-discover lessons from the early days of message-passing systems. Each of these is sometimes justified - the new constraints really are different - and sometimes pure pattern-blindness, where the new tooling makes the old solution invisible to engineers who only know the new one. The maturity to recognise the difference is a specific career skill.

Engineers often re-solve problems whose elegant solutions exist in older technologies.

The streaming-versus-broadcast specifics

For anyone planning streaming infrastructure today, the practical takeaway is to ask, for each use case, whether streaming is the right tool. Live one-to-many with no personalisation: broadcast or simulcast architecture, almost always. Personalised on-demand: streaming, definitely. Mixed live and personalised content: hybrid architectures that route the live segments through broadcast-style paths and the personalised parts through streaming. Most streaming products use full streaming for everything, which is over-engineered for the live cases and under-attentive to the cost structure.

The infrastructure decisions made during product launch tend to lock in for years. A live-events product launched on full streaming infrastructure will have streaming costs forever; a hybrid would have had a different cost trajectory. This compounds across thousands of small decisions, and the products that make the right architectural choices early have margin advantages that competitors can't easily catch up to. Engineering judgement at this layer matters more than most product decisions.

The respectful caveat

None of this is a criticism of streaming products specifically. Hotstar, Netflix, YouTube Live, Twitch, the BBC iPlayer - all of them are doing genuinely difficult engineering and producing genuinely valuable services. The point isn't that they're wrong to use streaming. The point is that the framing 'streaming is the modern solution to live video' overstates what streaming uniquely does and understates what broadcast still does well. Both architectures have a role. The teams that recognise this build hybrid systems that outperform either pure approach, and the teams that don't end up with infrastructure choices they regret in year five.

The original observation, then, is half right. We are re-solving the parts of broadcast that streaming has different constraints around, and we're solving genuinely new problems that broadcast couldn't address. The provocation is useful because it forces engineers to be specific about which problem they're actually solving and why the new architecture is justified for it. Most engineering teams would benefit from doing that thinking before they pick the architecture, rather than discovering the limits of their choice after the fact.