Reference
Gaffer On Games
Classic materials on the network model of real-time games and state synchronization.
Real-time Gaming - this is a system with strict latency restrictions, where not only scaling and fault tolerance are important, but also gameplay fairness. Architecture is usually based on authoritative server, event stream and regional placement of matches.
Requirements
Functional
- Matchmaking of players by rating, region and latency budget.
- A reputable game server with real-time state updates.
- Synchronization of positions/events (movement, shots, collisions, abilities).
- Support for reconnect and session recovery after short interruptions.
- Leaderboards, match statistics 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 + Scenario Explorer
Authoritative multiplayer topology with interactive scenario pathsAccess and Control Plane
Real-Time State and Data Plane
Main principle: tick loop should be isolated from slow external operations. Any heavy logic goes into the async pipeline outside the critical path.
Reliability and anti-patterns
Production patterns
- Region-aware placement: players match within the latency budget.
- Sticky session for a UDP/WebSocket stream within a match.
- Hot standby game servers and quick match reboot in case of node failure.
- Snapshot + delta updates to reduce bandwidth and fast resync.
- Backpressure/queue limits on ingress to protect the simulation loop.
Dangerous decisions
- P2P authoritative gameplay for competitive modes (high risk of cheating).
- Global matchmaking without regional segmentation by latency.
- Synchronous external calls (DB/HTTP) inside tick loop.
- Lack of reconnect window and state resync mechanisms.
- Too detailed full-state broadcast instead of compact diff packets.
What to store persistently
- Player profile and progress.
- Match history and key telemetry counters.
- MMR/ranking snapshots and leaderboard units.
- Inventory/economy events (if there is monetization).
- Audit trail for moderation and anti-cheat investigations.
During an interview, it is critical to discuss the trade-off between network smoothness (client-side prediction) and honesty (server authority + reconciliation + anti-cheat).
If the latency budget is exceeded, it is better to degrade matchmaking (region/rank) than to break the gaming experience.