How the sync layer works
What travels when a cue moves, what deliberately does not, and why the hardest part of real-time is deciding which changes are allowed to surprise someone mid-show.
One record, many readers
The shape is deliberately boring: there is one event record, and every surface is a subscriber to the part of it that concerns them.
The show caller writes. The graphics operator, the prompter, the signage and several thousand phones read. Nobody holds a private copy that has to be reconciled, because reconciliation is the failure this whole product exists to remove.
What travels
Changes to the event, as small units. A cue’s state. A session’s time or room. A speaker’s details. A published flag.
Small units matter more than they sound. Sending "cue 48 is now go" is a few dozen bytes and can be applied by a client that is a hundred cues away without touching anything else. Sending "here is the running order again" is orders of magnitude larger, and worse, it invalidates local state that was perfectly correct.
What deliberately stays put
This is the interesting half, and it is a design decision rather than a technical limit.
The prompter does not re-scroll under a presenter mid-sentence because someone corrected a typo four cues down. The caller’s current position does not move because a session two hours away was retimed. A surface that someone is actively acting from gets its updates queued and flagged, not applied underneath them.
The hardest problem in real-time is not speed. It is deciding what is allowed to surprise someone.
Two people, one cue
It happens on every large show: two people edit the same thing within the same few seconds, usually because both were asked to fix it and neither knew about the other.
Last write wins is the wrong answer here — it silently discards a decision someone made deliberately. Both changes are kept, the conflict is surfaced to whoever is holding the running order, and it is resolved by a person. In practice this is rare and takes two seconds; the alternative is a change that vanishes and is not noticed until it matters.
Venue wifi
Every assumption above has to survive the actual network conditions of an event, which are worse than almost any other production environment. A hall with four thousand phones in it is a hostile place for a radio.
So: a surface that loses its connection keeps working from what it last knew, and says clearly that it is doing so. It never blanks, and it never silently shows stale data as though it were live. When the connection returns it catches up from where it left off rather than reloading.
A prompter that goes white because the wifi dropped is worse than no prompter at all, because the presenter was relying on it.

Arena scale: one write, several thousand readers
Nicolae Ciobota
Founder, EventBlok. Live, hybrid and broadcast producer, showcaller and technical director, in production since 1996.
MORE FROM THE JOURNAL
- GUIDE
What is a showflow? A practical guide to the live-event running order
A showflow is the cue-level running order a production crew calls a live event from. This is what belongs in o…
- GUIDE
How to write a run of show for a live event
A run of show is the minute-by-minute document the production team delivers from. Here is the structure that w…
- GUIDE
Event agenda vs showflow vs run sheet: what each document is actually for
These three documents describe the same event to three different audiences, and confusing them is why events e…