# Scaling a consumer cloud platform to millions of carrier users

A consumer cloud product sold through T-Mobile, Verizon and TMcell had to grow from a single deployment to millions of users across three operators without losing uploads or sessions. This is how the platform was scaled and operated, told without the figures the operators have not cleared for publication.

Canonical: https://kitecorp.org/case-studies/telecom-scale-consumer-cloud
Updated: 2026-10-12

## What was the situation?

A consumer cloud product (storage, sync and media for subscribers' phones) was sold to mobile operators as a white-label service. Each operator switched it on for its own subscriber base and promoted it through its own channels, which meant the user count did not grow; it arrived. The same platform had to serve three operators with different integration points, different support organisations and different launch calendars, and it had to do so without a failure that any of them would have to explain to their customers.

## What did we change?

Capacity planning moved from the average to the surge. Every launch was planned from the operator's subscriber numbers and campaign schedule, load tested to the breaking point beforehand, and run with the on-call rotation and the rollback decided in advance. The services that absorb a surge (sign-up, authentication, sync, media upload) were separated from the rest so they could be scaled and protected on their own, with queueing and backpressure so a spike degraded gracefully instead of cascading. Operator integrations (provisioning, billing, support tooling) were isolated behind their own services so a change for one operator could not break another. Observability was rebuilt around the questions the on-call engineer asks first, and the alert set was cut to the pages a person could act on.

## What was the result?

The platform served millions of users across the three carriers. Launch days became planned events with a runbook rather than emergencies, and the operator reviews that gate each launch became a known part of the schedule rather than a surprise at the end. The figures behind this summary (peak concurrency, storage volume, uptime over the period) are the operators' to publish, and this page will carry them if and when they are cleared.

## What carried over to later engagements?

Three habits that now run through every Kitecorp engagement. Plan from the surge and test to the breaking point before launch, because the breaking point is the only number that matters on the day. Isolate the parts that absorb load and the parts that integrate with a partner, because both change on their own schedule. And build on-call around the pages a person can act on, because a page nobody can act on at three in the morning is the most expensive alert there is. The [telecom industry page](/industries/telecom) describes how those habits apply to operators and the vendors who sell to them.

## How to start

Send a message at https://kitecorp.org/contact or email admin@kitelang.cloud. Pricing follows a discovery call.
