Designing a Multiplayer Online Game Backend

Multiplayer game backends handle real-time state synchronization with strict latency requirements.

Architecture

Game Client
    ↓ WebSocket/UDP
Matchmaking Service
    ↓
Game Server (dedicated per match)
    ↓
Game State Store (Redis)
    ↓
Persistence Service (player stats, inventory)

Game Loop

Server runs at 60 ticks/sec (16.7ms per tick):
  1. Receive player inputs
  2. Apply game logic
  3. Update world state
  4. Broadcast state to all players
  5. Sleep until next tick

Network Protocols

TCP (WebSocket): Reliable, ordered
  → Use for: Chat, inventory, matchmaking
  → Problem: HOL blocking, retransmit delay

UDP: Unreliable, unordered, fast
  → Use for: Player positions, game state
  → Build reliability on top if needed

State Synchronization

Client-Side Prediction

Player presses W (move forward):
  1. Client immediately moves character (no lag)
  2. Client sends input to server
  3. Server authoritative result sent back
  4. Client reconciles if different

Lag Compensation

Player shoots at enemy at time T:
  Client renders at their current view
  But server sees player as 100ms behind

Lag compensation:
  Server rewinds world state by 100ms
  Check if shot would have hit THEN
  If yes → Register hit

Matchmaking

Factors:
  Skill rating (ELO/MMR)
  Geographic region (latency)
  Queue time (relax constraints over time)

Algorithm:
  Players added to matchmaking pool
  Find optimal group within skill band
  Create game server, notify players

Anti-Cheat

Server-authoritative: Never trust client
Speed check: Player moved too far in one tick?
Aim analysis: Inhuman accuracy? → Flag
Memory scanning: Client-side anti-cheat (VAC, BattlEye)

Conclusion

Game backends prioritize minimal latency. UDP for real-time positions, client-side prediction for responsiveness, server authority for cheat prevention.