Multiplayer game server - the server decides what happened

Why this design

A real-time multiplayer game is the purest latency problem in system design: the thing being served is a shared present that cannot exist, because every player receives it late. This question is asked for game studios and increasingly for anything real-time (trading screens, collaborative 3D, live sports betting). It tests whether you know the difference between an authoritative server and a relay, whether you can explain prediction, reconciliation, interpolation and lag compensation without hand-waving, and whether you can put a cost on a tick rate.

What you will learn

• Why the server owns the simulation and clients send only inputs - and why peer-to-peer and lockstep lose for a competitive shooter.
• The fixed tick: 64 Hz is a 15.625 ms budget, and what has to fit inside it.
• Client-side prediction and server reconciliation: your character moves now, and is corrected later if the server disagrees.
• Entity interpolation: why other players are drawn about 50 ms in the past on purpose.
• Lag compensation: rewinding hitboxes for a shot, who it is fair to, and why it is capped at 200 ms.
• Matchmaking, server allocation from a fleet, and why a match is a single process with no failover.

How to read this board

1. Press Play. GETTING INTO A MATCH: a ticket, a matchmaker, and an allocator that picks a server for ten players.
2. THE SERVER DECIDES: inputs arrive along the top, the tick runs, lag compensation rewinds for a shot.
3. The snapshot goes back to the PLAYERS, where the client reconciles itself and interpolates everyone else.
4. Then pages 1 to 6 and the DATA MODEL.
5. Argue with what the board leaves in: the death behind the wall, the cost of 128 Hz, and a match that dies with its process.

Ask these before drawing anything

• What kind of game? A 5v5 tactical shooter, a 100-player battle royale and a turn-based card game have nothing in common past the login screen. This board is a 5v5 shooter where hits are instant (hitscan).
• How competitive? Ranked play makes fairness and anti-cheat requirements; casual play makes cost the requirement.
• What latency is playable? Under 60 ms round trip feels good, 60 to 100 ms is fine, over 150 ms is a different game. That decides how many regions you need.
• Is the simulation deterministic? Lockstep (send inputs only, everyone simulates) needs bit-exact determinism across CPUs and waits for the slowest player. A shooter almost never chooses it.
• What happens when a server dies mid-match? Void, rematch or resume? Resume is very expensive; most games void.

Functional

• Matchmake ten players by skill and latency; place them on a server all ten reach in under 60 ms where possible.
• Run the match authoritatively at a fixed tick; clients send inputs, receive snapshots.
• Own-character movement responds instantly on the client; other characters move smoothly.
• Hits are judged against what the shooter saw, within a compensation window.
• Record results, rating changes and a kill feed; record the match for replays and cheat review.

Non-functional

• Tick budget 15.625 ms at 64 Hz, with simulation finishing in under 5 ms so a slow tick never cascades.
• Downstream bandwidth under 128 kbit/s per player, so the game works on a poor connection.
• Matchmaking median wait under 60 s at peak, under 3 min for the top 1 % of skill.
• Match crash rate under 0.05 %. A voided ranked match is a support ticket.

Out of scope

• Accounts, store and inventory.
• Voice chat (a separate relay service).
• Client-side anti-cheat drivers - mentioned only where server design affects them.