Two systems in lockstep
A live casino round is two things happening at once: a video stream from the table to the player, and a game engine that opens betting, accepts bets, receives the result, settles and pays. The product works when the two are in step: the player sees the dealer close betting at the moment the engine stops accepting bets, sees the wheel land at the moment the engine receives the result, and sees the payout appear as the dealer announces it. Every technical decision in live casino is about keeping those two systems synchronised at scale, across large numbers of concurrent players per table (some games, such as Evolution's Infinite Blackjack, offer an unlimited number of seats at a single table), on mobile networks of varying quality: in 2025 mobile accounted for 73 per cent of Evolution's revenue.
The video path
Capture and encoding. Cameras feed a production system at the studio that switches between shots (in game shows, a director does this) and encodes the output. Encoding decisions trade quality against latency: higher compression means smaller streams and more delay.
Distribution. The encoded stream goes to a content delivery network with edges near the players, so that a player in São Paulo watching a table streamed from Riga, where Evolution runs one of its three main production studios, is served from a nearby node rather than from the studio itself. Adaptive bitrate delivers several quality levels and the player's device switches between them to suit its network conditions. GLI-19, the Gaming Laboratories International standard for interactive gaming systems, requires each player to receive an equivalent quality feed, with a minimum connection requirement set and disclosed to the player.
Latency. The central constraint. A conventional streaming protocol delivers with many seconds of delay: standard HLS sends video in segments of several seconds (in Apple's example a regular segment is six seconds), and a player should not start playback less than three target durations from the live edge. That is fine for television and fatal for a game where betting must close before the result is known. Live casino uses protocols built for low delay, such as WebRTC, the W3C standard for real-time communication in browsers, or Low-Latency HLS, which splits media into partial segments of a few hundred milliseconds, to bring glass-to-glass latency close to real time. The engine's betting window is set with the worst expected latency in mind: betting closes in the engine before the dealer's "no more bets" reaches any player, and GLI-19 requires the system to prevent anyone from accessing the live game outcome prior to finalising a wager. Where a delay is apparent, the standard also requires its scale to be displayed to the player.
Resilience. Redundant encoders, redundant paths, and a fallback so that if the video degrades the game state is still delivered through the data channel and the round can complete or be voided cleanly. Players must be told in advance how interruptions are handled: GLI-19 requires the platform to describe its procedures for interruptions to data, video and voice, and in Britain the Gambling Commission requires interruption policies that do not systematically disadvantage customers (RTS 10). Evolution reported system availability of 99.90 per cent in 2025, excluding scheduled maintenance.
The game engine
The engine is a state machine per table: betting open, betting closed, result pending, result received, settling, paid, next round. Transitions are triggered by the dealer's interface (open, close) and by the recognition system (result), with the floor able to intervene (void, pause). The engine:
- Accepts bets from every player on the table within the betting window and rejects late ones with a clear message.
- Validates each bet against the table limits, the player's balance (via the operator's wallet) and the game rules.
- Receives the recognised result, compares it with the dealer's confirmation, and settles every bet according to the paytable. Unless corrections are made directly on the platform, recognition software must include a manual mode to correct a misread result, and players must be told when it is in use; where the physical device and the recorded outcome disagree, the device is treated as correct.
- Pushes the outcome and the new balances to every client and to the operator's wallet.
- Records everything: bets, timings, result, video timestamp, so that any round can be reconstructed. GLI-19 requires a continuous recording of every game, kept for at least ninety days or as the regulator requires.
The engine's load profile is spiky: a surge of bets arrives in the seconds before betting closes, settlement fans out to every connected client at once, and a popular game show or an unlimited-seat table can put a very large number of players on a single round.
Integration with the operator
The supplier's product reaches the player through the operator's site or app. The integration has three parts:
The wallet. Every bet debits the player's balance at the operator and every win credits it. Suppliers integrate through a seamless wallet API (the supplier calls the operator for each transaction) or a transfer wallet (funds move to a supplier balance for the session). Evolution states in its 2025 annual report that it is the operators that handle all monetary transactions with their end users. Seamless integration is widely used, and it makes the operator's wallet a dependency for every round: a slow wallet response delays bet acceptance, and a failed or timed-out one leaves a bet in doubt, which the player may think was placed while the engine has not accepted it. Wallet APIs therefore provide a way to reverse a debit for a bet that did not stand: an open-source implementation of Evolution's wallet API, for example, exposes a cancel call alongside debit and credit.
The lobby and launch. The operator embeds the supplier's lobby (the list of tables with live thumbnails and seat counts) or builds its own from the supplier's API, and launches a table in an iframe or a native view with a session token.
Reporting and reconciliation. Round-level data flows back to the operator for its records, its regulatory reporting and its reconciliation of the supplier's invoice. Discrepancies between the operator's wallet ledger and the supplier's round ledger are a recurring argument when invoices are settled.
The client
The player's interface overlays the video: the betting layout, chips, the timer, the statistics (recent results, hot and cold numbers), the chat, the balance, and the game show mechanics. It runs in a browser or a native wrapper, has to work on a mid-range phone on a mobile network, and has to keep the overlay and the video in sync so that the chip the player placed sits on the number they chose as the ball lands. Client performance is measured in bet acceptance rate (bets attempted versus bets accepted, which falls when latency or wallet delays push bets past the close) and in stream quality metrics.
Scale and multi-play
Players open several tables at once; suppliers offer multi-play interfaces and operators build lobbies that show dozens of live streams as thumbnails. The infrastructure implication is that the number of concurrent streams delivered far exceeds the number of players, and the CDN and encoding costs scale with streams. Suppliers can manage this with lower-quality thumbnail streams, lazy loading and limits on simultaneous full streams.
Monitoring
A live casino operation is monitored like a broadcaster and like a trading platform: stream health per table (bitrate, dropped frames, latency to edge), engine health (bet acceptance rate, settlement time, wallet response time per operator), recognition confidence, and business metrics per table (players, rounds, revenue). Alerts route to the studio control room and the engineering on-call, and a table with degraded stream or falling acceptance is taken offline before players notice, with its rounds voided if they cannot complete. Voiding is itself controlled: GLI-19 requires a mechanism for an authorised employee to void game results. Evolution, for example, says it monitors all gaming activities on its gaming floors in real time, 24 hours a day, with a Mission Control Room at each major studio.
Security
The stream is public to anyone with a session; the engine is not. Security work covers bet tampering (a client attempting to place a bet after close or alter a bet), session hijacking, wallet API abuse, and the studio's own network. In Britain the Commission's security requirements are based on the relevant sections of Annex A to ISO/IEC 27001:2022. At the studio, GLI-19 requires that dealers cannot manipulate the physical randomness devices except as the game design intends, and that access to studio equipment is controlled by a secure logon that locks after a period without input. Result manipulation at the studio is prevented by those controls, the recognition system's independence from the dealer, supervision of dealers, and a video recording of all dealer activity detailed enough to confirm whether procedures and game rules were followed (RTS 17).
The next lesson takes the outputs of all this, the recorded round and the recognised result, into the process that settles disputes and maintains the integrity of the game.