#40Live Sports Scores to Millions
Goal scored → 30M phones updated in <2s. Pub/sub fanout, edge delivery, thundering herd.

A goal is scored at minute 78. Within two seconds, thirty million phones — across continents, on 3G, on Wi-Fi, on the subway — must show the new score before the user feels it as late. The reads are the product. The writes are sparse (a goal happens, not 60 times a second), but the fanout factor is the design pressure: one publish must reach tens of millions of subscribers, and the on-field event rate spikes from 0 to ~5 events/second the instant something happens.

This is not the URL-shortener shape. The hot path is not a key-value lookup against a cache; it is sustaining a 30M-concurrent persistent-connection fleet, holding per-match subscriber lists in memory at the right shard, and absorbing reconnect storms when a PoP flaps. The single most important design decision is "where does the per-match fanout live" — and the answer (per-match actor sharded by hash(matchId), with a tree-relay topology activated for hot matches) determines the rest of the architecture.

Reading: Hotstar — 25.3M concurrent (Disney+Hotstar engineering) · Discord — Scaling Elixir to 5M concurrent (Manifold) · Cloudflare Durable Objects WebSocket Hibernation · Slack Flannel — application-level edge cache · SRE Workbook Ch.22 — Addressing cascading failures
pub/sub fanout
edge websocket termination
fan-out tree
thundering-herd reconnect
last-event-id replay
single-writer-per-match fencing
tiered storage
anycast
hot-key shielding