At Glastonbury in 2023, a crowd technology demonstration showed 60,000 phones lighting up within a single visual moment. From a distance, it looked simultaneous. In engineering terms, it was: the variance between first and last device receiving the trigger command was under 80 milliseconds, faster than the human eye can detect as sequential. That result doesn't happen with generic web technology. It requires a specific architecture built around real-time push communication.
Why standard HTTP requests don't work
The simplest way to send a command to many devices is HTTP polling: each device asks the server “what should I do now?” at regular intervals. The problem is latency accumulation. If each device polls every second, devices will receive commands anywhere from 0 to 1,000ms after the trigger, a variance that is visually obvious as a sweep rather than a flash. Even at 100ms polling, the variance is too high for synchronised effects.
HTTP polling also creates enormous server load at scale. 20,000 devices polling every 100ms means 200,000 requests per second to maintain. This is a bandwidth and compute problem that grows with the audience, making it expensive to scale and prone to degradation under peak load, exactly when you need it most.
How WebSockets solve the timing problem
WebSocket connections maintain a persistent, bidirectional channel between each client device and the server. Instead of polling, the server pushes commands to all connected clients simultaneously. The timing variance between client receipt of a broadcast command is determined by network propagation time, typically 5–30ms across a stadium's network, rather than polling interval.
The practical architecture for a stadium-scale system: a connection management layer handles WebSocket connections from fan devices, a message broker distributes commands across the connection pool, and a cloud compute layer scales horizontally to handle connection volume. Systems like Seatwave use infrastructure such as GCP Cloud Run and Pub/Sub to manage this: Cloud Run handles the elastic compute, Pub/Sub acts as the reliable message broker ensuring no command is lost during traffic spikes.
What 2,000+ concurrent connections per node actually means
Crowd display systems are tested against specific concurrency benchmarks because the load profile is unusual: many connections, relatively low message frequency, but zero tolerance for message loss during effect triggers. A tested concurrency of 2,000+ connections per node means the architecture can distribute load across nodes as fan connection volume grows, adding capacity horizontally rather than requiring ever-larger single servers.
For a 50,000-seat stadium at 70% participation, you're looking at 35,000 concurrent WebSocket connections. A system that handles 2,000 per node needs roughly 18 nodes to handle that load, well within elastic cloud scaling capability, but it needs to be sized and pre-warmed before the event, not scaled reactively after fans start connecting.
What to look for when evaluating a crowd display system
From a technical due diligence perspective, ask these questions:
- What is the tested concurrency? Not theoretical maximum, but tested, with load data to support it.
- What is the measured latency distribution? Average latency is less useful than 95th-percentile latency: what does the 5% worst-case device experience?
- How does the system handle connection loss? Devices drop connections. How quickly do they reconnect and resynchronise?
- What happens to queued commands during a traffic spike? If the broker is overwhelmed, do commands queue and deliver late, or drop?
- Is the infrastructure elastic and pre-warmed? Cold-start latency on cloud functions can add hundreds of milliseconds to the first trigger after idle periods.
Why the engineering matters to event teams
You don't need to understand WebSocket internals to run a crowd display event. But you do need to understand the engineering implications for your event planning. A system with proven sub-100ms latency at 2,000+ concurrent connections is one where you can trust the timing of your effects. A system where the technical specifications are vague, or where latency guarantees are conditional on ideal network conditions, is one where your halftime show may look patchy in practice regardless of how well you designed it.
Treat infrastructure benchmarks as part of your vendor evaluation, not a secondary consideration after pricing and design. The most beautifully designed crowd display effect is only as good as the infrastructure that delivers it.
Ready to turn your crowd into the canvas?
Seatwave turns every fan's phone into a synchronized pixel, controlled live from a single dashboard.