A multiplayer real-time game backend lives in a world of milliseconds: latency, jitter, and short disconnects are immediately visible to players instead of being hidden behind retries.
This chapter connects matchmaking, authoritative simulation, regional session placement, state update delivery, and reconnect recovery into one coherent system.
For interviews and engineering discussions, this case is useful because it quickly shows whether you can design under a hard latency budget without breaking gameplay fairness.
Latency Budget
Every extra hop between input and visible action is felt immediately, so latency must be budgeted per stage rather than treated as one abstract number.
Regional Matchmaking
You cannot mix players globally without thinking: region, network quality, and acceptable rank spread directly affect perceived fairness.
Authoritative Simulation
The server has to remain the source of truth for match state, or responsiveness quickly turns into cheating and client divergence.
Session Recovery
A short disconnect should not eject the player from the match, so reconnect windows, state snapshots, and fast resync need to be designed up front.
Reference
Gaffer On Games
Classic material on multiplayer networking models and state synchronization.
Real-time Gaming is a system with a hard latency budget, where scaling and fault tolerance run into one more requirement: the match has to feel fair. The architecture usually revolves around an authoritative server, regional matchmaking, and careful handling of jitter and reconnects.
Requirements
Functional
- Match players by skill, region, and latency budget.
- Use an authoritative game server that sends real-time state updates.
- Synchronize movement and gameplay events such as shots, collisions, and abilities.
- Support reconnect and session recovery after short disconnects.
- Expose leaderboards, match stats, and post-game events.
Non-functional
Latency: p95 < 80ms
Input-to-action latency should be predictable and low.
Tick Rate: 20-60 TPS
Stable simulation loop for fair gameplay.
Availability: 99.99%
The match should not fail due to the failure of one node/zone.
Fairness: anti-cheat + anti-abuse
The server validates actions, the client is not the source of truth.
Scale estimate
Every match is its own simulation process with a hard per-frame latency budget: at 60 ticks per second the whole simulation gets ~16.7 ms per frame, at 128 ticks only 7.8 ms. Scaling here is not “more replicas behind a load balancer” — it is managing a fleet of tens of thousands of independent game servers.
High-Level Architecture
Architecture and Scenario Explorer
Authoritative multiplayer topology with interactive scenario pathsAccess and control plane
Gameplay and data plane
The main rule: keep the simulation loop isolated from slow external operations. One synchronous database call inside a tick blows the frame budget for every player in the match, so heavy work belongs in asynchronous pipelines outside the critical path.
Client-side prediction and server reconciliation
GDC 2017
Overwatch Gameplay Architecture and Netcode
Tim Ford's talk on server authority, prediction, and rollback in Overwatch.
With a round-trip time (RTT) of 60-100 ms, the naive “press — send — wait for the server — move” loop makes controls feel sluggish: players notice the gap between input and motion at around 100 ms. So the client applies input immediately and locally, without waiting for the server — while the server remains the single source of truth that later confirms or corrects the result.
The prediction loop
- The client applies the input to its local simulation right away and stores it in a buffer of unacknowledged inputs with a sequence number.
- The same input goes to the server, which runs it through the authoritative simulation.
- The server replies with the confirmed state and the sequence number of the last processed input.
- The client compares the server state with its own prediction at that same sequence number.
- On a mismatch, the client rolls back to the server state and re-simulates every still-unacknowledged input from the buffer within a single frame.
Why it is the standard for shooters
- •Overwatch predicts everything by default — movement, abilities, and weapons — and the team explicitly opts out of prediction only for select effects such as large visible projectiles.
- •It is only safe to predict the deterministic, local part of the state: your own movement, animations, reload timers.
- •Outcomes that affect other players — damage, death, objective capture — are never declared by the client: only the server confirms them.
The cost of a misprediction is rubber banding: on a divergence the player snaps back to the server-confirmed position. The higher the packet loss and tail latency, the more frequent the rollbacks — so prediction quality depends directly on the transport and on regional server proximity.
State snapshots, delta compression, and tick rate
Reference
Quake 3 Network Model
A walkthrough of Quake 3 networking: snapshots, delta compression against the last acknowledged state.
The server broadcasts world snapshots to clients at the tick rate. Sending the full world every tick does not work: a snapshot of a 100-entity match takes several kilobytes, and at 60 ticks per second that is hundreds of kilobytes per second for every player. The classic answer from Quake 3 is delta compression: the server keeps a per-client snapshot history and only sends the difference against the last snapshot the client acknowledged.
How the delta loop works
- Client acknowledgements piggyback on regular inbound traffic — no separate requests.
- The server encodes a new snapshot as a diff against the last acknowledged one: only the changed fields of the changed entities.
- If an acknowledgement is lost, the server simply computes the delta from an older snapshot — there are no retransmits and nothing blocks.
- If the client falls too far behind, the server sends a full snapshot and the cycle restarts — the same path also covers reconnects.
Interpolation and extrapolation
- •The client renders other players in the past: it buffers two or three snapshots and interpolates smoothly between them. In the Source engine this window defaults to 100 ms.
- •When the next snapshot is missing, the client extrapolates motion from the last known velocity (dead reckoning) — a short packet loss stays invisible.
- •Long extrapolation is dangerous: the predicted trajectory diverges from reality, and characters start to “teleport” when the next snapshot arrives.
Tick rate: frame budget versus cost
| Tick rate | Frame budget | Where it shows up | Cost |
|---|---|---|---|
| 20-30 Hz | 33-50 ms | Battle royale and large worlds with 100+ players | Cheap servers, but hit registration delay is more noticeable |
| 60-64 Hz | ~16 ms | Overwatch (16 ms command frames), CS2 | A balance of responsiveness and cost for 10-12 player matches |
| 128 Hz | 7.8 ms | Valorant, esports configurations | Aggressive optimization: Riot pushed the server frame to ~2.6 ms to pack more matches per core |
The trade-off is transparent: doubling the tick rate nearly doubles the CPU cost of every match and the traffic, but shortens the gap between confirmations and makes delta sync more granular. So tick rate follows the genre: a tactical shooter needs 64-128 ticks, while a 4-player co-op game is fine at 20-30.
Interest management: who receives which part of the world
Delta compression shrinks the packet, not the recipient list. If each of 100 players must know about everyone else, the server emits roughly 100 × 99 updates per tick — at 30 ticks that is hundreds of thousands of records per second, a classic fan-out problem. Interest management solves it: every client subscribes only to the slice of the world that is actually visible and relevant to it.
Area-of-interest mechanics
- •The world is partitioned into cells — a spatial index on a uniform grid, or a quadtree when player density is highly uneven.
- •A client subscribes to its own cell and the neighboring ones; subscriptions move with the player, and hysteresis at cell borders dampens subscribe-unsubscribe flapping.
- •A client snapshot includes only entities inside its area of interest: the nearest 10-20 players instead of 99, so broadcast cost grows nearly linearly instead of quadratically.
- •Quake 3 did the same through the potentially visible set (PVS): the server kept a per-client snapshot history and serialized only the subset of state visible to that client.
Trade-offs and side effects
- •Cells too small mean heavy subscription churn while moving; too large means wasted traffic. Size is tuned to movement speed and view distance.
- •Sniper scopes, minimaps, and gunshot sounds break the simple geometry of the zone: they need separate interest rules with a different radius.
- •A fairness bonus: if enemy positions behind walls never reach the client, wallhack cheats have nothing to show. Visibility filtering is both an optimization and a defense.
Lag compensation: rewinding the world for hit checks
Valve
Source Multiplayer Networking
The canonical description of interpolation, prediction, and lag compensation in the Source engine.
Because of interpolation, the shooter aims at a picture from the past: the interpolation window plus the network path to the server easily add up to 100-150 ms of lag behind reality. If the server validated hits against current positions, perfectly aimed shots would routinely pass through their targets. That is why competitive shooters apply lag compensation under the favor-the-shooter principle.
The rewind mechanism
- The server keeps a ring buffer of every player's positions and hitboxes for the last second or so.
- On receiving a shot, the server computes the moment the shooter actually saw: current server time minus the packet's network latency minus the client's interpolation window — the formula from the Source engine.
- Target hitboxes are rewound into that past, and the hit is validated there.
- After the check the world returns to the present, and damage is applied to the current state.
The price of favor the shooter
- •The victim sometimes takes damage “behind cover”: from their point of view they already hid, but in the shooter's rewound past they were still visible.
- •The rewind window is capped at a few hundred milliseconds: a player with an enormous ping must not shoot into a too-distant past, or compensation turns into an artificial-latency exploit.
- •The favor-the-victim alternative (no compensation) is fairer to the victim but forces the shooter to lead targets by their ping — a worse deal for a mass-market product.
Compensation only works with an authoritative server: the client reports “I fired at this moment”, but the server decides on hits, damage, and ammo while validating fire rate, magazine state, and the physical reachability of the position. Any check delegated to the client eventually becomes a cheat — from aimbots to speedhack teleports.
Matchmaking and the game server lifecycle
Reference
Agones
An open-source platform by Google Cloud and Ubisoft for hosting and scaling game servers on Kubernetes.
Matchmaking and server allocation form a pipeline with its own trade-offs: the longer a player waits, the wider the system is willing to interpret a “suitable” match — both in rating and in latency.
From the Play button to the first tick
- The client measures RTT to regional points of presence and attaches the results to its ticket along with rating and game mode.
- The ticket enters the matchmaker queue; the accepted rating and latency windows widen as the wait grows — that is the explicit trade-off between match quality and queue time.
- For an assembled group, a region with acceptable RTT for the majority is chosen and a server is requested from the warm pool — allocation takes seconds because the processes are already running.
- Players receive the server address and a one-time session token; the server validates tokens, waits for connections, and starts the match.
- After the match, the server flushes results into the persistent pipeline — ratings, stats, economy — and either returns to the pool or shuts down to make room for a new one.
Fleet management
Running a fleet of game servers is its own class of infrastructure with off-the-shelf options.
- •Agones — an open-source project by Google Cloud and Ubisoft: GameServer and Fleet resources on top of Kubernetes, eviction protection for pods with active players, and health checks through a lightweight SDK.
- •Amazon GameLift — the managed counterpart: multi-region placement, allocation queues, and FleetIQ for saving money on Spot instances.
- •In both cases the key difference from web workloads: a server with a live match cannot be killed on scale-down — it holds match state until the last player leaves.
Scaling for the peaks
Autoscaling a game fleet works differently from typical web services.
- •The scaling metric is not CPU but the buffer of ready servers: “keep N idle processes per region”, with forecasts based on time of day and event announcements.
- •Scaling down means draining: a node stops receiving new matches and waits for the current ones to finish, so shrinking the fleet takes tens of minutes.
- •Regular heartbeats from the game process separate stuck servers from busy ones: a silent process with a live match is an incident, not a candidate for silent replacement.
Transport: UDP, reliability channels, and browser games
TCP guarantees ordering and delivery but pays with head-of-line blocking: one lost packet delays everything behind it until the retransmit arrives, and the client then receives a burst of stale states at once. For game state, freshness beats completeness, so the main traffic runs over UDP with guarantees assembled selectively at the application layer.
Channels with different guarantees
- •Unreliable sequenced — state snapshots: a newer packet makes the older one worthless, so packet loss is tolerable and stale packets are simply dropped by sequence number.
- •Reliable ordered — events that must not be lost: an item purchase, a round start, a chat message. On top of UDP this means sequence numbers, an acknowledgement bitfield, and retransmits for this channel only.
- •Separate channels keep reliable traffic from blocking the fast path: even under packet reordering, snapshots keep flowing without queuing.
In the browser: WebRTC and WebTransport
- •Browsers have no raw UDP, so browser games use WebRTC DataChannel: SCTP over DTLS, where ordered: false with maxRetransmits: 0 behaves like encrypted UDP. The server simply acts as a regular WebRTC peer.
- •WebTransport over QUIC is the simpler client-server alternative: unreliable datagrams and streams without head-of-line blocking, minus the ICE signaling ceremony.
- •NAT traversal is trivial in the client-server model — the client always initiates the connection; STUN and TURN matter mostly for P2P modes and voice chat.
Picking a transport per traffic type
| Transport | Guarantees | Where it fits |
|---|---|---|
| UDP + custom reliability layer ✓ | Configurable per channel | Game state for native clients: snapshots, inputs, shots |
| TCP / WebSocket | Reliable, ordered | Lobby, matchmaking, chat, store — everything outside the game tick |
| WebRTC DataChannel | Configurable: from UDP-like to fully reliable | Browser clients talking to a dedicated server peer |
| WebTransport / QUIC | Datagrams and streams without head-of-line blocking | A modern replacement for both browser options as support matures |
The practical rule: the fast path carries only data that becomes worthless after one tick; everything else moves to a regular reliable channel. That way packet loss degrades the picture but never breaks match integrity.
Reliability and anti-patterns
In production you plan sticky sessions, overload protection through backpressure, and a recovery path after short disconnects up front — otherwise the first node failure or load spike tears a match apart instead of degrading it gracefully.
Reliable patterns
- Region-aware placement: try to match players within the latency budget.
- Sticky sessions for match-scoped UDP/WebSocket traffic.
- Hot standby game servers and fast match recovery after node failure.
- State snapshots plus delta updates to reduce bandwidth and speed up resync.
- Backpressure and queue limits at ingress to protect the simulation loop.
Common mistakes
- A P2P model with the client as the source of truth in competitive modes.
- Global matchmaking with no regional segmentation by latency.
- Synchronous calls to databases or HTTP services inside the game tick.
- No reconnect window or state resync path after disconnects.
- Full-state broadcasts instead of compact delta packets.
What to persist
- Player profile and progress.
- Match history and key telemetry counters.
- MMR snapshots, ranking results, and leaderboard aggregates.
- Inventory and economy events if the game has monetization.
- Audit trail for moderation and anti-cheat investigations.
In interviews, call out the trade-off between responsiveness from client-side prediction and fairness enforced by server-side authority, reconciliation, and anti-cheat.
If the latency budget is exceeded, it is better to relax region or rank constraints in matchmaking than to let the match degrade into visible lag.
Related chapters
- UDP protocol - covers the primary low-latency transport used for fast-path gameplay networking.
- WebSocket protocol - complements gaming systems with persistent realtime channels for lobby events and selected state updates.
- Chat System - provides an adjacent realtime case around messaging, presence, and scaling long-lived connections.
- Rate Limiter - helps protect game APIs against abuse traffic, bursts, and unfair client behavior.
- Content Delivery Network (CDN) - explains asset and patch delivery acceleration with regional latency optimization for players.