Consider what happens the moment a goal celebration effect is triggered at a 55,000-seat stadium. In under 100 milliseconds, every connected phone needs to receive the command, parse it, and execute the colour change or flashlight activation. That's not a problem you can solve by making a single server faster. It's an architecture problem, and the answer is a publish/subscribe messaging pattern running on infrastructure that scales horizontally on demand.
Why a single WebSocket server hits a ceiling
WebSocket connections are stateful and persistent. Each open connection consumes server memory. A single Node.js server, well-tuned, might handle 10,000–20,000 concurrent WebSocket connections before latency and reliability start to degrade. A stadium event with 50,000 fans, even at 60% participation, is already beyond that threshold. The naive solution (make the server bigger) works up to a point, but vertical scaling has limits and creates a single point of failure. Horizontal scaling, where multiple server instances share the connection load, is the right approach. But it introduces a new challenge: how do you broadcast a command to connections spread across multiple instances?
Pub/Sub as the coordination layer
Google Cloud Pub/Sub solves the cross-instance coordination problem. When the admin operator triggers an effect, the command is published to a Pub/Sub topic. Every Cloud Run instance running the WebSocket server is subscribed to that topic. Each instance receives the message and immediately pushes it to every WebSocket connection it's managing. The result: a single effect trigger fans out to all connected devices across all instances, with no direct instance-to-instance communication required.
Seatwave's architecture runs on this model. Cloud Run instances scale automatically based on connection volume. Pub/Sub handles the messaging fan-out. The operator fires one trigger; the message reaches tens of thousands of devices in parallel.
Why GCP Cloud Run suits this workload
Cloud Run's automatic scaling is particularly well-suited to event-driven workloads. In the 90 minutes before a major stadium event, connections ramp quickly as fans arrive and join the display. Cloud Run provisions additional instances to match demand without manual intervention. After the event, instances scale back down. For a crowd display platform where events are episodic (a club might run 25 home matches per season), this pay-per-use, scale-on-demand model is significantly more cost-efficient than maintaining fixed infrastructure sized for peak load.
Multi-instance deployments across stadium zones
Some stadium configurations require zone-specific deployments: different sections of the venue may be managed as separate display zones, each with its own configuration or effect sequence. In this model, multiple display instances run concurrently, each subscribed to a different Pub/Sub topic or filtered subscription. The admin dashboard aggregates all zones into a single seat map view, but the operator can target effects to specific zones or broadcast to all simultaneously. This is useful for:
- Running different sponsor activations in premium vs. general admission sections
- Staging effects that travel physically across the stadium (the wave effect originates in one zone and propagates to adjacent zones in sequence)
- Testing new effect sequences in a specific section before broadcasting to the full stadium
- Handling legacy connectivity issues in specific areas with localised fallback configurations
Latency characteristics at scale
The sub-100ms latency benchmark refers to the time from effect trigger to device execution. At scale, this involves: operator action to Pub/Sub publish (network dependent, typically under 10ms), Pub/Sub delivery to subscribed instances (typically 20–40ms), and WebSocket push from instance to device (typically 10–30ms, depending on device network quality). The sum under normal network conditions is comfortably within 100ms for the vast majority of connected devices. Outliers, devices on poor mobile signal, may run slower, but these are a small fraction of the total and don't affect the visual quality of the effect from the stands.
Architecting a crowd display system for stadium scale is not a one-server problem. It's a distributed systems problem, and Pub/Sub messaging on a horizontally scalable cloud runtime is the approach that makes full-stadium, sub-100ms effect propagation achievable without overprovisioning or operational complexity.
Ready to turn your crowd into the canvas?
Seatwave turns every fan's phone into a synchronized pixel, controlled live from a single dashboard.