Multiplayer game servers synchronize game state across all players in a session with minimal latency. The design must handle packet loss, network jitter, and cheating.
Game Session Architecture
Dedicated game servers host individual match sessions. Session lifecycle: created → waiting_for_players → in_progress → completed. Game: game_id, map_id, max_players, status, region, server_ip, server_port, created_at, started_at, ended_at. Player: player_id, game_id, user_id, team, spawn_position, ping_ms, is_connected.
UDP vs TCP
UDP is preferred for real-time game state due to lower latency. TCP reliability adds head-of-line blocking and retransmit delays that are unacceptable for game state. The game implements its own reliability layer on UDP for critical packets (connect, disconnect, game events). Unreliable packets are used for high-frequency state updates such as positions — old packets are discarded when a newer one arrives.
State Synchronization
The server is authoritative. Each tick (64Hz = every 15.6ms), the server processes all player inputs received since the last tick, simulates physics and game logic, and generates a world snapshot. The snapshot contains all entity positions, health, and events. The server sends delta snapshots (only changed entities) to each client to reduce bandwidth. Clients interpolate between received snapshots for smooth rendering.
Lag Compensation
When a player shoots, their view is delayed by their ping (e.g., 80ms behind server time). The server rewinds game state to the player’s client time when evaluating shot hit detection — this compensates for round-trip latency. The maximum rewind window equals the maximum acceptable ping (e.g., 300ms). The rewound state is computed from a circular buffer of historical world snapshots.
Matchmaking
The matchmaking service groups players by skill rating (MMR), ping to available server regions, preferred game mode, and party constraints. Elo or Glicko-2 is used for MMR. The matchmaking queue is a priority queue sorted by wait time multiplied by a quality weight. Once a match is found, a server is allocated from a warm server pool and its IP is returned to all matched clients.
Anti-Cheat
The server validates all player actions server-side, rejecting impossible movement speed or kill distances. An optional intrusive client-side anti-cheat agent monitors memory for known cheat signatures. Statistical anomaly detection flags players with abnormal accuracy or unrealistic reaction times. Flagged players are queued for manual review or auto-banned if confidence is high.
Frequently Asked Questions: Multiplayer Game Server
Why do multiplayer game servers prefer UDP over TCP for real-time game state?
TCP’s reliability mechanisms—retransmission of lost packets and in-order delivery—introduce head-of-line blocking. When a packet is lost, the TCP stack stalls subsequent data until the missing packet is retransmitted and acknowledged, which can add tens to hundreds of milliseconds of latency. For real-time games, a stale position update from 200 ms ago is worthless; it is better to drop it and process the next fresh update. UDP has no built-in reliability, so the game layer sends position and state updates continuously at a fixed tick rate (e.g., 20–64 Hz) and simply discards old datagrams that arrive out of order, achieving far lower and more consistent latency.
How does delta snapshot compression reduce bandwidth in a game server?
Instead of sending the full game state every tick, the server tracks the last acknowledged snapshot for each client and sends only the fields that changed since that baseline—a delta. Each delta packet encodes changed entity IDs and their updated attributes (position, velocity, health) using bit-packing or variable-length encoding. The client maintains its own state and applies deltas on top. If a delta packet is lost, the server can reconstruct a new delta against an older acknowledged baseline. This typically reduces per-tick payload by 60–90% compared to full snapshots, directly lowering bandwidth and packet loss probability.
How does lag compensation via state rewind work in a multiplayer game?
The server maintains a circular buffer of world state snapshots timestamped by server tick. When a player fires a shot, the client sends the action with the client-side timestamp. The server calculates the player’s round-trip latency, rewinds its state buffer to the snapshot that corresponds to what the client saw at the moment of the action, performs hit detection in that historical state, and then returns to the present to apply the result. This ensures that a player with 100 ms latency is not unfairly penalized for shooting at a target that was in a different position by the time the packet arrived.
What is the difference between Elo and Glicko-2 for MMR rating calculation?
Elo is a single-number rating system where each player has a rating R and an expected win probability is calculated from the difference in ratings. After a match, ratings are updated proportional to a K-factor times the surprise (actual minus expected outcome). Elo does not account for rating uncertainty. Glicko-2 extends Elo by adding a rating deviation (RD) that represents uncertainty—a player who has not played recently has a higher RD—and a volatility parameter that tracks inconsistency in performance. Glicko-2 updates are applied in rating periods rather than after every game, making it more stable and better suited to systems where players are inactive for stretches of time.
What are the main server-side anti-cheat validation approaches?
Authoritative server architecture is the foundation: the server owns the truth and never trusts client-reported outcomes. Specific techniques include: speed and position validation (reject any movement that exceeds the maximum possible velocity given elapsed time); rate-of-fire validation (reject weapon actions that fire faster than the weapon’s defined RPM); reachability checks (verify that a player’s reported position is physically reachable from their last known position without passing through solid geometry); statistical anomaly detection (flag players whose headshot ratios, reaction times, or aim patterns deviate far from population norms); and replay analysis (store full tick-level server logs for flagged sessions and run offline classifiers against them to confirm violations before issuing bans).
See also: Meta Interview Guide 2026: Facebook, Instagram, WhatsApp Engineering
See also: Snap Interview Guide
See also: Databricks Interview Guide 2026: Spark Internals, Delta Lake, and Lakehouse Architecture