We found the capacity on the servers they already had

3.3× concurrent capacity in under six months. No new servers, and we never touched the transcoding farm.

Mobinet did not come to us with a cost problem. They came with a growth plan. They wanted new features, new business models and superapp services. And they had set a clear target: triple the subscription base.

The usual way to do this is to buy more infrastructure first. More subscribers watch more content, so you add servers before the growth arrives, not after.

We took a different route. To prove it worked, we kept two things fixed.

First, the hardware. Fifty-five platform servers before, fifty-five after. In the same period, concurrent capacity went from 30,000 viewers to 100,000. This took less than six months, including the migration from their previous platform.

Second, and this matters more: we did not touch the transcoding farm. No new servers, no new profiles, no change to the encoding ladder.

Why the second point is the interesting one

Ask most operators what limits concurrency. They will say encoding capacity, bitrate or CDN throughput. Video delivery is where the cost is most visible, so people assume the limit must be there as well. When a platform struggles at peak time, the next investment usually goes into video processing.

Mobinet’s limit was somewhere else.

The constraints were in the platform architecture, applications, backoffice, the database and the architecture of the analytics servers. There were further limits at the origin and edge nodes. In other words, the problem was in the systems that track who is watching not in the systems that deliver what they watch.

This makes sense when you look at how each type of work grows.

Every viewer who starts a stream creates a session. That session must be authenticated. Entitlements must be checked. The player sends regular status signals. Analytics records all of it. With tens of thousands of viewers at the same time, these small transactions add up to a very large load.

That load grows with the number of viewers. The transcoding farm’s load grows with the number of channels. These are two different curves. Add ten thousand viewers and the encoders barely notice. The database notices immediately.

So the transcoding farm was never the problem. It had enough capacity all along.

What we changed

Three areas: catch-up storage, session and concurrency handling, and the behaviour of the origin and edge nodes.

For catch-up we used a method we call Chronostream, now patent pending. The idea is simple. Most recorded content is never watched. The small part that is watched is requested by many viewers at the same time, and usually from the same recent programmes. If you size storage for everything you keep, you buy far more fast storage than you need. If you size it for what is actually read, the requirement falls sharply.

The session work addressed the control-plane limit directly: the cost of tracking each viewer, which is what multiplies as concurrency grows.

Customer satisfaction went up during this period, not down. That is worth saying, because efficiency gains often cost quality. Here that was unlikely: we never changed the encoding ladder, so picture quality was not something we could trade away.

What this means for a growth plan

Capacity and volume are not the same thing. Being able to serve three times more viewers is not the same as actually delivering three times more hours. At Mobinet, both grew. Subscribers increased and viewing increased. The capacity was already there, and it had cost nothing to create.

That is the whole mechanism. The cost base stayed the same while delivered hours went up. So the cost of delivering one hour of viewing fell, with no new investment behind it.

This is the part worth remembering. When an operator plans to triple its subscriber base, it usually assumes the infrastructure bill will triple as well. That assumption goes into the business case and decides whether the plan can be afforded. It is rarely tested.

Buying more hardware is the fastest answer to a capacity limit, and it does work. It is also the most expensive way to solve a problem that, in this case, was not in the hardware at all.

If you want to know where your own limit sits, and what growth would really cost you, start with one number: what one hour of viewing costs you to deliver today. Our calculator is free and anonymous. No sign-up, seven monthly figures, about four minutes.

→ morescreens.com/calculator

We will be at IBC2026, 11–14 September at the RAI in Amsterdam, stand 1.F11.