At 400ms delay, a colour wave sent to 20,000 phones looks like a slow smear across the crowd. Individual phones light up in visibly different stages: you can see the lag travel from section to section. At 80ms, the same wave reads as a single moving object. The human visual system starts to perceive delay above roughly 100–150ms, which is why that threshold matters for any effect that requires the crowd to move together.
What latency actually means in this context
In a crowd display system, latency is the time between the admin triggering an effect and every connected phone updating its screen or flashlight. This isn't a single measurement. It's a distribution. At 2,000 concurrent connections, some phones will update in 40ms, some in 90ms, some in 140ms. The p95 or p99 latency figure, the time by which 95% or 99% of devices have updated, is the number that actually defines visual quality.
A system that achieves 50ms average latency but has a 600ms p99 tail will still show visible stragglers. Platforms built on GCP Cloud Run with Pub/Sub fan-out are designed to manage this tail: the message broadcast happens at infrastructure level, not application level, which keeps the distribution tight.
Why WebSocket architecture matters here
Latency in crowd display is predominantly determined by the connection architecture. HTTP polling, where each phone periodically checks for updates, introduces inherent delay equal to the polling interval. A phone polling every 500ms will always have average latency above 250ms.
WebSocket connections solve this: the server pushes updates to every connected phone the moment a command is issued. There's no polling interval. The limiting factor becomes network propagation and device processing time, which, for a modern phone on a decent mobile connection, is measured in tens of milliseconds.
At the Johan Cruijff ArenA scale (54,000 capacity), you need an architecture that can fan out a single admin command to tens of thousands of WebSocket clients simultaneously. This is where cloud Pub/Sub becomes essential: it decouples the broadcast from any single server instance and scales horizontally without adding latency.
The effects where latency is most visible
Not all effects expose latency equally. A static colour hold (every phone stays one colour for 30 seconds) requires no synchronisation precision. But these effects show latency clearly:
- Directional waves: the wave shape depends on phones updating in precise spatial sequence. High-latency tails produce a blurry trailing edge
- Simultaneous flashlight pulses: a crowd-wide flash that triggers 300ms apart across sections looks like a ripple instead of a pop
- Beat-synced effects: at 120 BPM, a beat falls every 500ms. If your p95 latency is 400ms, devices are updating during the next beat window
- Scripted multi-stage sequences: effects that chain transitions rapidly require consistent sub-100ms updates at each stage
What 2,000-connection validation tells you
A platform validated at 2,000+ concurrent connections with sub-100ms latency has stress-tested the architecture under realistic conditions. This isn't a theoretical spec. It means the message fan-out, WebSocket management, and cloud infrastructure have been measured under load.
For events scaling beyond 2,000 connections, horizontal scalability on Cloud Run means additional instances handle additional load without re-architecting. The Pub/Sub layer ensures that adding instances doesn't fragment the broadcast: every instance receives the same command at the same moment.
Latency under load, not peak latency in a test environment, is the number that matters for a live show. That distinction is worth asking any platform vendor to clarify before your event goes live.
Ready to turn your crowd into the canvas?
Seatwave turns every fan's phone into a synchronized pixel, controlled live from a single dashboard.