Study guide 148 of 183

Multiplayer game servers

How real-time multiplayer games keep players in sync: authoritative servers, tick rates and snapshots, client prediction and reconciliation, lag compensation, UDP networking, interest management, server allocation and fleets, persistence, cheating and scaling to large worlds.

Reading is half of it. See this used in a real interview: walk through Design a Matchmaking System →

A fast-paced online game must make every player feel their actions happen instantly, while all players see a consistent world, over networks with 30 to 150 ms of latency and occasional packet loss. Games solve this differently from web systems: a single authoritative simulation per match, running in fixed ticks, with clients predicting ahead. "Design the backend for a multiplayer game" usually combines this with matchmaking and leaderboards.

Authoritative servers

Each match runs on a dedicated game server that owns the true game state:

Clients send inputs (move, shoot), not results.
The server simulates the world and sends state snapshots back.
The server validates everything, which is the foundation of cheat prevention: a client cannot simply claim it hit someone.

Peer-to-peer models exist (common in fighting games and older titles) but make cheating and NAT traversal harder.

Ticks and snapshots

The server runs the simulation at a fixed tick rate (for example 20, 30, 60 or 128 ticks per second).
Each tick it processes inputs received, advances physics and game logic, and sends updates.
Snapshots are delta-compressed against the last state the client acknowledged, so only changes are sent.

Higher tick rates feel more responsive but cost more CPU and bandwidth per match, which directly affects how many matches fit on a server.

Networking

UDP, with a custom reliability layer: unreliable for frequent state (a lost position update is replaced by the next one), reliable and ordered for important events (chat, item pickups).
Small packets, bit-packed state, and rate limits per client.
Clients connect to servers in nearby regions; matchmaking selects regions by measured ping. See matchmaking and skill rating.

Hiding latency

Client-side prediction: the client applies the player's own inputs immediately instead of waiting for the server.
Server reconciliation: when the authoritative state arrives, the client rewinds to it and replays unacknowledged inputs; small corrections are smoothed.
Entity interpolation: other players are rendered slightly in the past, interpolating between snapshots, so they move smoothly.
Lag compensation: when a shot arrives, the server rewinds other players' positions to what the shooter saw at the time, so hits feel fair to the shooter (at some cost to the target).

Interest management

Large worlds cannot send everything to everyone. Each client receives updates only for entities relevant to it (nearby, visible, on its team). Spatial partitioning (grids, cells) decides relevance. See geospatial and proximity.

Server fleets and allocation

Game servers are processes or containers, many per machine, allocated per match by a fleet manager when matchmaking forms a match.
Fleets autoscale per region with warm capacity, since players will not wait for machines to boot. Peaks follow time of day and launches. See autoscaling.
Servers are stateful during a match; deploys drain by letting matches finish, not by killing them. See stateful vs stateless services.
Open-source and managed tools (Agones on Kubernetes, cloud game server services) handle allocation and scaling. See Kubernetes for system design interviews.

Persistence

Match results, progression, inventories and currencies live in backend services and databases, not on game servers:

At match end, the server reports results to a results service (idempotently, with a match id), which updates ratings, leaderboards and rewards. See Design a Leaderboard and idempotency keys in practice.
Virtual currency and purchases need ledger-style correctness. See payments and ledgers.
Persistent worlds (MMOs) checkpoint world state to databases periodically and shard the world into zones or instances, each simulated by a server.

Cheating

Server authority over game state and hit validation.
Rate and plausibility checks on inputs (impossible speeds, aim snapping).
Client anti-cheat software and statistical detection from match data, with reviews and bans.
Never send clients information they should not see (enemy positions behind walls), which defeats wallhacks at the source. See trust and safety.

Friends, parties, chat, presence and notifications use the same backends as social apps. Chat and presence are connection-gateway problems; parties feed matchmaking. See presence and connection management.

In the interview

"Matchmaking forms a match and asks the fleet manager for a server in the best region from a warm pool; clients connect over UDP; the authoritative server ticks at 30 Hz, sending delta-compressed snapshots filtered by interest; clients predict their own movement and interpolate others; the server lag-compensates hits. At match end, results are posted idempotently to the backend, which updates ratings, leaderboards and rewards." See Design Matchmaking.

Checklist

Authoritative dedicated servers; clients send inputs.
Fixed tick rate, delta-compressed snapshots, UDP with selective reliability.
Prediction, reconciliation, interpolation and lag compensation.
Interest management for large worlds.
Regional fleets with warm capacity and match-aware draining.
Idempotent result reporting; ledger-grade virtual economies.
Server-side validation and information hiding against cheats.