The pattern, then the product
Many clients. One authoritative state.
Every screen correct.
Phones, tablets, desktops and browsers, all reading and writing the same record at the same time, all expecting their screen to be right. The server owns the state. Conflicts are settled in one place, and the result is pushed to every connected screen. That is the whole pattern.
It is the shape of most systems that feel alive: a dispatch board, a pick queue, an auction floor, a blotter. The engineering underneath is the same four disciplines every time. Writes are ordered. State is committed before it is announced. Operations tolerate being called twice. And the clock runs on the server, because the world does not pause when a user closes a tab. Get all four right and the screens agree. Get one wrong and two people act on two different versions of reality.
We built a product on exactly this pattern. It is live, it is ours, and you can test the claim in the next five minutes.
The proving ground
Ours is live. It plays bingo.
MyEventBingo is our own product, built and operated by this firm. It runs bingo games for live events, and the bingo is the least interesting thing about it. What matters is what has to be true for it to work at all: a room full of players on their own phones, one game state on the server, and every board still correct while that state changes underneath it.
A game is an unforgiving place to prove this pattern. An enterprise user who sees a stale screen files a ticket. A player who sees a stale board says so out loud, in a room full of witnesses, immediately. A warehouse is more demanding about correctness; a room full of players is more demanding about immediacy. The architecture has to satisfy both.
- Open myeventbingo.com on your laptop and on your phone.
- Join the same game from both.
- Watch each join arrive on the other screen. When the game starts, both screens start. When it pauses, both pause. Nobody refreshed anything.
It is free to play. No purchase, no wagering, no prizes of monetary value. Just the state-management demonstration, running in public.
Under the hood
What is actually running.
No block diagram with clouds on it. Here is the machinery, named.
One shared Razor component library ships into five render contexts: server-rendered web, WebAssembly in the browser, and native Windows, iOS, and Android apps through .NET MAUI. The stack is .NET and Blazor, Hybrid on the apps and Auto render on the web. The components a player sees on a phone are the components on the desktop.
Live updates move over SignalR against a named event contract: game started, game over, paused, resumed, square taken, player joined. Named events, not a generic "something changed" ping. A connected screen is told exactly what happened. It does not poll and hope.
Gameplay mutations pass through a server-side command queue and are processed in order. State is committed to the database before it is broadcast, so the update a player sees describes a write that already happened. The screen is a receipt, not a promise.
Join is explicit and idempotent by design. Call it twice, from a flaky connection or an impatient double-tap, and it returns the board you already have rather than issuing a second one.
A background lifecycle scheduler advances game state on time thresholds even when no client is connected. A game that should end at nine ends at nine, whether or not anyone's browser is open, because the clock does not stop when the browser closes.
Azure SQL. Text columns are Unicode by default, because names arrive in every alphabet, with a short, tracked list of exceptions for fixed-format fields. Schema migrations are applied by the application at startup, not run by hand from somebody's laptop.
The browser surfaces are exercised end to end with Playwright, driving the running app rather than a mock of it. Five render contexts mean five different ways for the same component to behave, so behavior is tested, not assumed.
The transfer
You do not run bingo. You run this shape.
Strip the game off and look at the frame: many concurrent clients, one authoritative server state, ordered writes, real-time fan-out, and a clock that acts when nobody is watching. None of that machinery knows it is running a game. Here is the same frame in five rooms where nobody is playing, and for each one, the specific property that transfers.
Twelve dispatcher screens and forty trucks look at one board. Two dispatchers grab the same unit in the same second. In this shape their commands land in a server-side queue and are processed in order: the first assignment commits, and the second dispatcher is answered from state that already contains it. The property that transfers is ordered, server-resolved writes.
A handheld times out on warehouse Wi-Fi and the picker taps again. In the game, joining twice returns the board you already have instead of issuing a second one. On a pick screen, the identical behavior means a retried claim returns the task you already hold instead of minting a duplicate. The property that transfers is idempotency under retry.
A bid that displays before it commits is a lawsuit. The rule the game runs on, committed before broadcast, is the rule an auction floor needs: the high bid on every screen is a high bid the database already stored. And lots that close on the clock, watched or not, are the lifecycle scheduler under a different name. The properties that transfer are durable-before-visible and time-driven state.
A ward board that announces "moved to recovery" before the record commits has invented a patient location. The game's contract, named lifecycle events broadcast after the write lands, is the contract a clinical board needs, with game started and game over standing in for admitted and discharged. The property that transfers is the commit-then-broadcast event contract.
A trader's screen drops for ten seconds in a tunnel, and live updates arrive only while the connection is up. What was missed is not lost: the server keeps the authoritative, ordered record, and on reconnect the client reconciles against it rather than guessing from the last thing it saw. The property that transfers is reconciliation against an authoritative server, and it deserves its own section.
One straight answer
The wire is best-effort. The server is not.
A live connection over the public internet is best-effort, and no amount of code changes that. A phone in an elevator misses updates while it is out of range. That is a fact of networks, not a defect. What decides correctness is what happens next: the server keeps the authoritative, ordered record of the game, and a client that reconnects reconciles against that record and converges on the server's version rather than guessing.
A vendor who promises exactly-once delivery over the public internet is selling something. The engineering answer has not changed in decades: do not trust the wire, make the server the single source of truth, and let the client reconcile against it. We would rather put that on a marketing page than have you find it in an incident review.
Next
The product proves the pattern. The pattern is for hire.
If you are responsible for a dispatch board, a pick screen, an auction floor, a status board, or a blotter, you already run this shape. We build it as a custom engagement: your domain, your rules, this architecture.