Design a Multiplayer Game Backend

Level Expected:

Interview Setup

Interview Prompt

Design a multiplayer game backend supporting 10M concurrent players across 500K game sessions at 30 ticks/sec, with 300M state updates/sec and client-side prediction for responsive gameplay.

Clarifying Questions (ask before designing)

Question	Why it matters
Authoritative server or peer-to-peer with host migration?	Server-authoritative prevents cheating at the cost of additional latency, whereas peer-to-peer networking minimizes latency but exposes the game to memory manipulation.
Tick rate: 20, 30, or 60 ticks/sec?	30 ticks/sec allows 33ms per tick, while 60 ticks/sec doubles bandwidth from 300M to 600M updates/sec.
Game type: FPS (where lag compensation is critical) or turn-based (which is latency tolerant)?	FPS games require rollback lag compensation, while MOBAs prioritize interest management over precise hit detection.
Max players per session: 10, 100, or 1000?	100 players multiplied by 30 ticks and state payload size dictates the required bandwidth per game server.

Scope

In scope

Game loop tick rate
Client-side prediction
Server reconciliation
Lag compensation
Spatial partitioning (interest management)
UDP vs TCP

Out of scope (state explicitly)

Detailed frontend/UI pixel implementation
Org structure, staffing, and hiring plan

Functional Requirements

Clarify game type and session size before drawing architecture diagrams, because an FPS operating at 30 ticks/sec with lag compensation requires a vastly different architecture than a 4-player cooperative lobby. Confirm whether matchmaking, persistence, and anti-cheat are in scope for this round.

Real-time game state synchronization running at a fixed tick rate of 20 to 60 ticks/sec
Matchmaking service grouping players of comparable skill into balanced game sessions
Lobby management to create and join custom rooms, invite friends, and coordinate ready status
Authoritative player input processing with server-side validation to eliminate speed and teleport cheats
Persistent player progression, including match history, inventory, and experience points
Global and seasonal rankings integrated with a high-throughput Leaderboard System
In-game text and voice communication channels
Replay capture subsystem capable of recording and replaying full match tick histories
Delayed spectator stream mode to prevent tactical ghosting
Cross-platform networking supporting PC, console, and mobile clients

Non-Functional Requirements

Interviewers probe latency first, so call out the tick budget (~33ms at 30 ticks/sec) and explain why UDP is preferred over TCP for position updates before they ask. Server-authoritative consistency and anti-cheat are the other non-negotiables.

Ultra-Low Latency: Target < 50ms round-trip network latency, ideally under 20ms within regional clusters
Authoritative Tick Rate: Server processes physics and broadcasts state 20 to 64 times per second
High Availability: 99.9% uptime, because a game server crash abruptly terminates the active match
Strict Consistency: The server is authoritative, ensuring all clients converge on the same physical game state
Scalability: Support 10M+ concurrent players across 500K+ concurrent game sessions
Anti-Cheat Rigor: The server validates all physical actions, treating every connected client as untrusted

Capacity Estimations

Run the bandwidth math early because naive all-to-all fan-out is what breaks this design at 10M concurrent players. Interest management is not an optimization; it is the difference between 1.5 TB/sec and an infrastructure cost that can actually be provisioned.

Metric	Calculation	Value
Concurrent players	Given	10M
Concurrent game sessions	Given	500K
Tick rate	Given	30 ticks/sec
Total state updates / sec	10M players x 30 ticks/sec	300M
Network per player	Given	~150 KB/sec
Total bandwidth	Given	1.5 TB/sec
Game servers needed	Given	~50K

Bandwidth derivation: 10M concurrent players receiving 30 state updates per second at roughly 50 bytes per compressed delta yields a 150 GB/sec baseline. A naive all-to-all broadcast where each player receives all other entity positions produces a 10x amplification, ballooning egress to approximately 1.5 TB/sec before spatial filtering. Spatial partitioning through grid cells cuts effective egress to approximately 150 GB/sec by limiting updates to 10 to 15 nearby entities, marking the difference between an economically viable deployment and an impossible network configuration at global scale.

Architecture Diagram

In the interview room, clarify the game type before drawing, because an FPS operating at 30 ticks/sec with lag compensation differs fundamentally from turn-based lobby architectures.

The architecture bifurcates into two distinct networking planes: HTTP and WebSocket services manage matchmaking, party lobbies, and player profiles, while high-frequency UDP transports the authoritative 30-tick/sec game simulation loop. Once the matchmaker groups compatible players, it provisions a dedicated game server container through Agones, allowing clients to exchange input and state packets with sub-50ms latency using client-side prediction.

At 300M state updates per second across 500K concurrent sessions, Agones manages pre-warmed pod pools, while a decoupled Kafka message pipeline processes post-match side effects, including leaderboard updates, player XP, and anti-cheat telemetry, safely off the tick hot path.

Component Deep Dives

Netcode architecture is where staff-level candidates distinguish themselves. We step through client prediction and server reconciliation for local responsiveness, lag compensation for fair hit registration, and interest management for bandwidth containment.

Netcode: Client-Side Prediction and Server Reconciliation

A 50ms network round-trip introduces an unplayable delay if clients wait for server acknowledgment before rendering character motion. Prediction masks this latency while reconciliation preserves server authority.

Problem: 50ms round-trip creates a 50ms delay between pressing "move" and seeing movement.

Solution: Client-Side Prediction + Server Reconciliation
  1. Player presses "move forward".
  2. Client immediately moves character locally in the predicted direction.
  3. Client dispatches input packet to server containing tick timestamp and input vectors.
  4. Authoritative server simulates physics movement and transmits authoritative coordinates.
  5. Client receives server state for past tick T:
     - If coordinates match prediction: proceed without correction.
     - If coordinates diverge: rewind local entity to server coordinate at T and replay subsequent inputs.

Netcode: Entity Interpolation and Lag Compensation

Interpolation renders smooth opponent movement between discrete server packets, while server-side lag compensation ensures fair hit registration across varied latencies.

Interpolation (rendering remote opponents):
  Render other players ~50ms in the past (one tick behind).
  Smoothly interpolate positions between the two most recently received server ticks.
  Result: continuous visual motion despite discrete 33ms network packets.

Lag Compensation (server-side hit validation):
  Server rewinds world state to "favor the shooter".
  1. Player fires at tick 100, viewing opponents rendered at tick 99.
  2. Server receives firing packet and rewinds opponent hitboxes to tick 99 coordinates.
  3. Server traces raycast against historical hitboxes: if valid, register hit and apply damage.
  Trade-off: maximizes shooter accuracy responsiveness, occasionally causing targets to take damage near corner edges.

Matchmaking: Glicko-2 Rating and Queue Expansion

The matchmaker balances competitive match parity against queue waiting times, expanding rating search radiuses dynamically.

Queue process:
  1. Player enters matchmaking queue with rating, rating deviation, and regional affinity.
  2. Initial search: seek exact rating match (+/-50 rating points within local region).
  3. Dynamic widening: widen search window as wait time increases (+/-100, +/-200, then cross-region).
  4. Match quality evaluation: 1 - (avg_rating_diff / max_diff) * (1 - wait_penalty).
  5. Allocate match once quality score clears the regional acceptance threshold.

Search radius progression over queue wait time:
  0-30s:   +/-100 rating (tight, highly competitive)
  30-60s:  +/-200 rating
  60-120s: +/-400 rating
  120s+:   +/-1000 rating (prioritize game launch over strict parity)

State Compression and Interest Management

Delta encoding and entity prioritization reduce bandwidth requirements by an order of magnitude across massive multiplayer sessions.

Delta compression: transmit only modified fields relative to last acknowledged tick.
  Stationary players generate 0 bytes of coordinate payload.
  Typical compressed delta size: 200 bytes compared to 2 KB full snapshot (10x reduction).

Priority-based update frequencies:
  Immediate combat vicinity: full broadcast rate every tick (30 updates/sec).
  Distant visible entities: reduced broadcast rate (10 updates/sec).
  Obscured or off-screen entities: suppressed or baseline heartbeats (2 updates/sec).
  Combined bandwidth reduction: 5x to 10x savings across the fleet.

Event Bus Design (Kafka)

Asynchronous event streaming isolates post-match accounting, XP calculations, and anti-cheat audits from the real-time physics loop.

Topic: match-results
  Partitions: 64 (partition by match_id)
  Retention: 7 days
  Producers: Game Server on match end (scores, duration, player stats)
  Consumers: Leaderboard Service (ZINCRBY), Profile Service (XP/currency), analytics warehouse

Topic: player-session-events
  Partitions: 128 (partition by player_id)
  Events: joined_lobby, match_started, disconnected, reconnect, cheat_flagged
  Consumers: Matchmaker (skill rating Glicko-2 updates), anti-cheat pipeline, presence service

Topic: anti-cheat-reports
  Low volume, containing server-authoritative violation signals
  Consumers: ban enforcement, manual review queue

Game tick path stays UDP, reserving Kafka exclusively for durable post-match and meta-game side effects.

API Design

Matchmaking and Lobby REST Endpoints

Standard RESTful endpoints govern pre-game flows such as queuing, lobby formation, and profile retrieval. Once matched, the client receives connection credentials and transitions entirely to UDP.

HTTP

# Matchmaking endpoints
POST /api/matchmaking/queue
DELETE /api/matchmaking/queue
GET /api/matchmaking/status

# Lobby endpoints
POST /api/lobbies
POST /api/lobbies/{id}/join
POST /api/lobbies/{id}/ready
POST /api/lobbies/{id}/start

# Game session connection descriptor returned to client
# { "game_server": "gs-us-east-42.game.com", "port": 27015, "token": "jwt..." }

# Profile and Leaderboards
GET /api/players/{id}/stats
GET /api/leaderboard?season=s12&page=1

Common Error Responses

JSON

400 Bad Request: invalid input, missing required fields, or malformed JSON payload
401 Unauthorized: missing or invalid authentication token or API key
403 Forbidden: authenticated caller lacks required permissions for this resource
404 Not Found: requested resource ID does not exist
409 Conflict: duplicate write or version conflict, retry with a unique idempotency key
422 Unprocessable Entity: syntactically valid request failed semantic business validation
429 Too Many Requests: rate limit quota exceeded, client should honor Retry-After header
500 Internal Error: unexpected server failure, retry safely with an idempotency key
503 Service Unavailable: downstream dependency is unavailable or overloaded, retry with exponential backoff
440 Login Timeout: WebSocket connection session expired, client reconnect is required

Data Model

PostgreSQL: Persistent Player Profiles and History

Relational storage manages durable player accounts, Glicko-2 ratings, and historical match outcomes with ACID guarantees.

SQL

CREATE TABLE players (
    player_id UUID PRIMARY KEY,
    username TEXT UNIQUE,
    rating FLOAT DEFAULT 1500.0,
    rating_dev FLOAT DEFAULT 350.0,
    volatility FLOAT DEFAULT 0.06,
    matches_played INT DEFAULT 0,
    wins INT DEFAULT 0,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE match_history (
    match_id UUID,
    player_id UUID,
    team INT,
    result TEXT CHECK (result IN ('win','loss','draw')),
    kills INT DEFAULT 0,
    deaths INT DEFAULT 0,
    rating_change FLOAT,
    played_at TIMESTAMPTZ,
    PRIMARY KEY (match_id, player_id)
);

Redis and S3 Match Storage

Redis powers ephemeral matchmaking queues and live season leaderboards, while S3 archives compressed game replay blobs.

REDIS

# Matchmaking queue ordered by MMR rating
ZADD mm:queue:{region} 1540.50 player_uuid_101

# Active session routing metadata
HSET game:session:{game_id} server "gs-42" region "us-east" port 27015

# Seasonal competitive leaderboard
ZADD leaderboard:season:s12 1850.25 player_uuid_101

# S3 Replay Archive
Path: s3://replays/{match_id}.bin
Format: Compressed Protobuf tick log (gzip)
Storage Footprint: ~5 MB per 20-minute match session

Fault Tolerance

Technique	Application
Agones orchestration	Maintain a pre-warmed server pool with automated replacement of crashed pods.
Health checks	Edge gateways continuously monitor game server health and route players to healthy sessions upon failure.
UDP resilience	Lost packets are discarded while client-side interpolation smooths over missing ticks.
Kafka RF=3	Match results and player events survive broker failures through replication.
Redis Cluster	Session state and real-time leaderboards survive node failures via clustering.

Game Server Crash Recovery Strategies

Failure recovery differs based on the competitive stakes and duration of the match session:

Short casual matches (< 10 min):
  Match is declared void and discarded without impacting player ratings.

Ranked competitive matches:
  1. Game server writes incremental state checkpoints to Redis every 30 seconds.
  2. Upon container failure, Agones spins up a replacement container and loads the latest checkpoint.
  3. Connected clients reconnect automatically and resume play from the 30-second boundary.

Tournament esports matches:
  A warm shadow server ingests mirrored input packets in parallel.
  Upon primary failure, the gateway promotes the shadow instance with under 1 second of interruption.

Server-Authoritative Anti-Cheat Architecture

Treating game clients as untrusted rendering displays eliminates the vast majority of traditional multiplayer exploits:

Server-authoritative physics completely eliminates:
  Speed hacking, coordinate teleportation, invincibility, item duplication, and shooting through solid geometry.

Mitigating client-side perception hacks:
  Wallhacks: Occlusion culling ensures the server only transmits coordinates of entities within active line-of-sight.
  Aimbots: Statistical anomaly analysis detects inhuman angular velocity and sub-millisecond snapping, flagging accounts for automated bans.

Additional Considerations

Transport Protocol Selection: UDP vs TCP

The choice between UDP and TCP stems from whether real-time immediacy or guaranteed in-order delivery is critical to the game system.

TCP Characteristics:
  Guarantees delivery and strict packet ordering.
  Drawback: Head-of-line blocking stalls all incoming traffic if a single packet drops.

UDP Characteristics:
  Provides minimal connectionless packet delivery without retransmission delays.
  Receiving tick 101 immediately is far more valuable than waiting for a delayed tick 99 retransmission.
  Interpolation seamlessly bridges single-packet drop gaps.

Protocol Allocation:
  Use TCP for: party chat, marketplace transactions, inventory management, and kill feed notifications.
  Use UDP for: character coordinate streams, physics simulations, and continuous world snapshots.

Game Server Orchestration with Agones

Agones extends Kubernetes with custom resource definitions designed specifically for stateful, long-lived game server containers.

Agones lifecycle management:
  1. Maintains a warm buffer pool of "Ready" game server pods across regional clusters.
  2. Matchmaking service invokes Agones allocation API requesting a server in the target region.
  3. Agones transitions pod status from Ready to Allocated, returning public IP and UDP port.
  4. Matchmaking gateway provides connection token to players, who connect directly via UDP.
  5. Match concludes: server signals Agones to transition to Shutdown, prompting container teardown.

Interview Walkthrough

25-minute cut
Focus on the authoritative 30-tick game loop, UDP transport rationale, and client prediction.
- 30 ticks/sec authoritative server: establish the 33ms fixed tick budget (8 min)
- UDP for real-time game state alongside TCP for inventory and chat (9 min)
- Client-side prediction with server reconciliation to eliminate perceived input lag (8 min)
Lead with server-authoritative design, where the server owns physics, health calculations, and inventory while clients transmit inputs rather than authoritative positions.
Employ UDP for position ticks where the latest state supersedes older packets, while relying on TCP for chat, inventory transactions, and kill feeds where reliability is mandatory.
Walk through the fixed 33ms tick loop budget: receive, validate, simulate, snapshot, broadcast, and record.
Detail delta-encoded personalized snapshots: each client receives only what changed within its active viewport rather than the entire world state.
Explain entity interpolation: client engines render smooth opponent motion by interpolating between known server states approximately 50ms behind real-time.
Highlight game server lifecycle management with Agones, explaining how pre-warmed pod pools minimize matchmaking wait times.
Contrast lag compensation against client prediction, walking through the server-side rewind algorithm for fair hit registration.
Identify the common pitfall of selecting TCP for real-time movement, where head-of-line blocking on a single lost packet freezes state processing until retransmission completes.

Engineering Trade-offs

Multiplayer backends continuously balance server-authoritative simulation accuracy against client responsiveness and network bandwidth.

The Game Loop: One Tick End-to-End (33ms Budget)

Every tick must complete well within the 33ms threshold to prevent server frame drops and client stuttering.

Server tick rate: 30 ticks/sec yields 33ms per tick.

Tick 1042 processing schedule:
  T=0ms:   RECEIVE: Ingest all pending UDP client input packets (~60 player inputs).
  T=2ms:   VALIDATE: Inspect each input for speed hack violations, cooldowns, and bounding boxes.
  T=8ms:   SIMULATE: Run physics integration, projectile raycasts, and collision checks.
  T=15ms:  SNAPSHOT: Assemble authoritative world delta for tick 1042.
  T=18ms:  BROADCAST: Dispatch delta-compressed UDP packets tailored per player interest area.
  T=22ms:  RECORD: Append tick delta to in-memory replay ring buffer.
  T=23ms:  IDLE: 10ms safety headroom reserved for physics collision spikes.

Total execution: ~23ms utilized of 33ms budget, preserving a 10ms buffer for peak combat.

Entity Interpolation: Making Other Players Move Smoothly

Interpolating between past server states ensures fluid opponent rendering without requiring excessive network tick rates.

Without interpolation: Opponent characters appear to teleport every 33ms.
With interpolation: The client renders opponent positions smoothly between two acknowledged states.

Client renders between known server snapshots (lagging real-time by ~50ms to 100ms):
  T=0ms:   Player rendered at (100, 50) [tick 100]
  T=11ms:  Player rendered at (101.7, 50) [one-third interpolation]
  T=22ms:  Player rendered at (103.3, 50) [two-thirds interpolation]
  T=33ms:  Player rendered at (105, 50) [tick 101]

Trade-off:
  Remote opponents render slightly in the past, necessitating lag compensation for hit detection.
  Competitive esports titles increase server tick rates to 64 or 128 ticks/sec to compress this window.

Help Us Improve

How helpful was this walkthrough?

Click a star to rate. We actively use this feedback to refine and update our system design content.

Placeholder

Discussion

Share your thoughts, ask questions, or help others.

Loading comments...

◉Interview Setup