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 matter, but gameplay fairness matters just as much. 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.
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. Heavy work belongs in asynchronous pipelines outside the critical path.
Reliability and anti-patterns
In production, you need a clear plan for sticky sessions, overload protection, and fast recovery after short disconnects instead of hoping the transport layer will hide them.
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.