Scaling New Heights: Livepeer Integration for initially 50k+ Concurrent Viewers With Unlimited Viewer abilities as we scale up.
By DeHub Team — 2025-03-14
In Q1 2025 we integrated Livepeer, supporting more than 50,000 concurrent viewers with, in principle, unlimited capacity on higher spend tiers.
Why not just add servers
Because concurrency is the specific thing that does not scale by adding servers.
Fifty thousand people watching fifty different streams is a manageable distribution problem. Fifty thousand watching one stream, at once, in real time, from everywhere, is a different problem entirely — and it is the one that matters, because the streams that decide a platform's reputation are exactly the ones with a large simultaneous audience.
A platform that handles ordinary load well and fails at a creator's biggest moment has failed at the only moment anyone will remember.
Why Livepeer specifically
It fits the direction we had already committed to.
DePIN Phase 1 went live in Q4 2024, beginning the work of distributing video delivery across independently operated infrastructure rather than concentrating it with a few providers. Livepeer is decentralised transcoding and delivery, which makes it the same argument applied to the most expensive part of the pipeline.
That matters beyond principle. A centralised provider is a single commercial relationship that can be withdrawn, repriced or subjected to a jurisdiction's requirements. For a platform whose entire proposition is that creators should not be exposed to unilateral decisions by intermediaries, running all delivery through one is an obvious inconsistency.
The honest framing of "unlimited"
The bullet in our roadmap says unlimited in theory on higher spend tiers, and the qualifier is doing real work.
Capacity above the tested level is a function of what you are willing to pay for. There is no architectural ceiling in the way there is with a fixed fleet, and there is very much a commercial one. We tested to 50,000+. Beyond that is a budget question, and we would rather state it that way than imply a number nobody has verified.
What it needed underneath
The 200% backend improvement from Q3 2024, without which none of this would have been survivable, and the custom CDN reaching sub-200ms globally shipped alongside it.
Those two are complementary rather than alternatives — Livepeer handles transcoding and distribution at scale, and the CDN determines how quickly the result reaches a particular viewer.
Together with 99.99% uptime in the same quarter, they are the numbers that let us make the decentralised-delivery argument without asking creators to accept a worse stream for it. That was always the condition. A principle a viewer can perceive as buffering is not a principle anyone will adopt.
Concurrency is a reputation problem
The reason we treat this as a priority rather than a capacity planning exercise is that the failures are not evenly distributed in their consequences.
A platform that handles ordinary streams well and struggles at 20,000 concurrent viewers has not failed 0.1% of the time. It has failed during the events that define what people think of it — the tournament, the launch, the collaboration that brought a new audience in.
Those are also the streams most likely to be clipped, screenshotted and discussed. A buffering failure at that moment does more damage than a month of flawless ordinary operation repairs.
So the capacity target is not set by average load. It is set by the largest thing a creator might plausibly do on the platform, which is a much more expensive number to design for and the only defensible one.