Edge-deployed venue compute for live sports operations
The product was a new-concept real-time sports operations platform — a small team, multiple third-party integrators, and a tight delivery window against a category nobody else had tried. The architectural question was where compute should live: the 2026 default would route everything through a central cloud tier.
We chose to put it at the venue instead. Each venue runs an identical containerised Node web stack; central holds cross-venue ops. Outside live games the architecture looks more expensive than the cloud-only alternative. During live games the trade-off inverts: games can’t pause because connectivity dropped.
Games kept running when networks failed. Local interactions ran at sub-100ms feedback loops. Adding venues scaled near-linearly because most load lives at the edge, not central. The operational tax is real — running infrastructure at N venues is harder than running it in one cloud — and we’d still make the same call.
- Each venue runs an identical containerised Node web stack, kept current via image-pull updates
- Event-driven sync-back to a central store; venues are the source-of-truth during games, central is source-of-truth across them
- Multiple third-party integrators connect at the venue tier, not centrally — N venues scale near-linearly without proportional central load
- Sub-100ms feedback loops on local-game interactions that would be impossible from the cloud