Live score fan-out: how one six reaches 50M phones

Rohit Sharma hits a six, and 50 million phones need to show it within seconds. The design that handles this is a classic fan-out problem, and it comes down to one writer per match, a replicated cache, and many push servers.

Why polling breaks

The obvious approach is to let every phone keep asking the server whether anything changed. With 50 million phones doing that, everything breaks. The server spends its time answering the same question over and over, and the load grows with the audience instead of with the match.

So the flow runs the other way. A score is written once, copied out, and pushed to phones.

One writer keeps the order

A scorer logs every ball. Those updates go to a score writer, and there is one writer per match.

The reason is ordering. One writer keeps one order of balls, so nothing clashes. If several writers could save updates for the same match, you would have to reconcile who saw what first. With one, you don't.

A replicated cache for reads

Once the writer saves Rohit's six, it lands in a cache, which is a saved copy of the current state. Reading from a copy is cheap.

But one copy can't serve millions of readers. So the cache is replicated, meaning it is copied across machines. Many copies share the read load, and the writer still stays single.

Push servers hold the connections

While your app is open, it holds one live connection. The server can send the update down that connection when the score changes, and the phone never has to ask.

50 million open connections don't fit on one machine. They are split across many push servers, with the sockets sharded between them. Each server holds its share of phones and passes along the new score from the cache.

Put together, the path reads like this. The scorer logs the ball, the score writer for that match saves it, the replicated cache holds many copies, the push servers hold the sharded sockets, and the phones show the six.

What to expect

Delivery takes seconds, not instantly. It is best-effort, and that is a fair trade for a design that doesn't fall over when everyone is watching the same over.

Next time a system design interview asks you to push a score to millions of users, walk through it in that order: one writer, replicated copies, many push servers. Then say out loud which part scales which problem. Writes stay ordered, reads spread across copies, and connections spread across servers.