Live Sports Scores Are a Fan-Out Problem, Not a Chat Problem

If you are building a live score product, stop copying chat architecture. Live sports is a fan-out problem. One source of truth changes rarely (a goal, a wicket, a foul), and hundreds of thousands of viewers need the same tiny update at the same instant. That is the opposite of chat, where every client is also a writer. Get the shape right and one modest box serves a stadium's worth of fans. Get it wrong and you pay for a bidirectional pipe you never use.

Why live scores are not like a chat app

In chat, every connection is a potential producer. Ten thousand users means ten thousand possible writers, each generating messages the server must accept, order, and re-broadcast. In a live score feed, there is exactly one producer: your ingest pipeline reading the official data. Every other connection is a pure consumer.

That difference changes everything downstream. You do not need per-client write authorization on the hot path. You do not need message ordering between clients. You do not need to worry about one abusive client flooding the room. You need to take a single state change and copy it to a very large number of sockets as fast and as cheaply as possible.

Treat it like chat and you inherit chat's costs for no benefit. This is the same mistake I see teams make when they reach for a real-time database instead of a custom backend: the generic tool assumes bidirectional traffic and prices you for it.

Model one authoritative source, broadcast read-only

The clean design has three layers. Ingest normalizes the official feed into your own event model. A single authoritative state per match lives in memory, updated only by ingest. A broadcast layer fans that state out to every subscribed viewer.

Keep the authoritative state small and versioned. Each match has a monotonically increasing version number. When something changes, bump the version and push a delta, not the whole scoreboard. Sending deltas instead of full state matters more here than almost anywhere, because you are multiplying every wasted byte by your entire audience. A full scoreboard payload at 4 KB across 200,000 viewers is 800 MB per update. A 40-byte delta is 8 MB. Same information.

Viewers subscribe to a match channel and receive deltas. They never write to it. If a viewer also posts reactions or predictions, route that through a separate channel with its own rules, so the read path stays clean and cheap. This is exactly the case for designing pub/sub channel granularity deliberately instead of dumping everything on one topic.

Scale by match room, not by connection

The instinct is to count connections. The right unit is the match. A popular final might hold 300,000 viewers; a mid-week regional game holds 400. Your cost is dominated by the hot matches, and within a match, cost is dominated by fan-out volume, not connection count sitting idle.

So partition by match. Each match room owns its authoritative state and its subscriber set. When you need more capacity, you move whole rooms to other nodes and let a pub/sub backplane carry deltas between them. This is the same principle as scaling real-time rooms, not connections: the room is the thing you shard on.

Idle connections are cheap if you built them cheap. The expensive moment is the goal in a big match, when one event fans out to everyone at once. Size your headroom for that peak fan-out event, not for the average.

Handle the reconnect storm at the whistle

Two moments break naive live-score backends: kickoff and halftime. At kickoff, everyone connects in a narrow window. At a big moment, a flaky network drops a chunk of viewers who all reconnect within seconds. Both are thundering herds.

Guard against them. On connect, hand the client the current state version immediately, then stream deltas from there, so a reconnecting viewer does not need a full replay. Stagger reconnect backoff on the client so drops do not sync up into a wall. If you already understand reconnection in real-time apps, apply the same discipline, just at a much larger blast radius.

What this means for your stack

If your product is scores, tickers, live odds, or race positions, you want a backend tuned for one-to-many broadcast with tiny deltas and room-based sharding, not a general chat engine. That is precisely the shape a purpose-built real-time layer like AltoHost is designed for: authoritative state, delta fan-out, and horizontal room scaling without you hand-rolling a backplane. If you are still deciding what you need, evaluate a real-time backend against your actual peak fan-out numbers, not a vendor's connection-count vanity metric.

The rule holds across the category: live sports is broadcast. Build the broadcast, and 200,000 fans cost you almost nothing between goals. For infrastructure built around exactly this pattern, AltoHost is where I would start.