Live Dealer Latency Spikes 380ms When the Table Fills

Live dealer blackjack tables get measurably slower as they fill up. When a seven-seat table goes from three occupied seats to six, median round-trip latency climbs from roughly 210ms to 590ms — a 380ms jump that players feel as a stutter between the deal and their turn. That figure comes from a set of 12,000 hands logged across four studios between January and March 2024, and it holds up whether the player is on fibre in Frankfurt or 4G in Manila.

Where the milliseconds actually go

The obvious suspect is the video feed, and it's part of the story but not the whole one. Studios typically push 1080p at 60fps through a WebRTC stack, and adding seats doesn't change the bitrate much — the encoder is already running. What changes is everything downstream of the camera.

Each occupied seat generates its own state sync: bet placement, chip animations, side-bet toggles, and a chat message every few seconds in a busy room. On a six-seat table that's six clients sending acknowledgements back to the game server, plus the dealer's terminal confirming each action. The server serialises those events, and the slowest client in the room sets the pace for everyone.

The numbers break down roughly like this:

• Video encode and transit: 90–130ms, fairly stable
• Game server round-trip: 40ms on an empty table, 180–260ms at six seats
• Client-side render and input handling: 30–60ms depending on device
• Dealer confirmation on the physical terminal: 20–40ms, spikes when the dealer corrects a misread bet

That middle line is the one that moves. It's not linear either — the curve bends sharply past four seats.

The four-seat cliff

Studios rarely publish seat-by-seat latency, but the internal data tells a consistent story. Three seats sits around 210ms median. Four seats, roughly 300ms. Five seats, 430ms. Six seats, 590ms. Seven seats — the full table — regularly tips past 700ms on peak evenings, and the 95th percentile touches 1.1 seconds.

Why the bend? Two things stack. First, most live blackjack tables run a single-threaded game loop per table, so actions queue rather than parallelise. Second, dealers are trained to a rhythm, and that rhythm assumes a certain pace of player decisions. When five people are each taking three to five seconds to hit or stand, the dealer's own confirmation step gets squeezed, and the terminal queues.

Roulette hides this better because the spin cycle is fixed and bets can be batched. Blackjack exposes it because every seat makes a discrete, timed decision.

What operators do about it

The cheap fix is capping seats at five during peak hours. A few operators already do this on their highest-traffic tables, quietly, and the latency numbers improve by roughly 30%. The trade-off is obvious: fewer seats per table means more tables, more dealers, more studio floor space.

The better fix is architectural. Some newer studios run per-seat game threads with optimistic state updates — the player's action renders immediately on their client while the server reconciles in the background. This cuts perceived latency by 150–200ms even when the true round-trip hasn't improved. It also introduces a new problem: what happens when the reconciliation fails and the player sees a card that never existed?

The question nobody wants to answer

If a table is measurably slower at six seats than at three, and the house edge doesn't change, does latency itself become a fairness issue? Players on slow connections already make worse decisions under time pressure — auto-stand kicks in, or they misclick. A 380ms penalty isn't rigging, but it isn't neutral either.

The uncomfortable part is that seat count is a business decision, not a technical one. Studios know the curve. They also know that a full table earns more per dealer hour than a half-empty one. Whether that trade is worth 380ms depends entirely on who you ask — and the players feeling the lag aren't usually the ones being asked.