Multiplayer Game Server — Authoritative Dedicated Server

The dedicated authoritative server architecture is the industry-standard approach used by virtually every competitive multiplayer game in production — Valorant, Fortnite, Rocket League, Overwatch, and Counter-Strike. It solves the three fundamental problems that make client-hosted P2P unworkable for competitive play: host advantage, cheating, and host disconnection.

The key architectural shift from P2P to authoritative is moving the game simulation from a player's machine to a neutral dedicated server. In the authoritative model, no client runs the game simulation. Instead, a dedicated GameWorker process (one per match) runs the authoritative game loop at 60 ticks per second. Clients send only their inputs (movement vector, shoot command, ability activation) to the server. The server validates every input server-side — this is anti-cheat by design, not by detection. The server simulates the game state, and broadcasts state snapshots back to all connected clients. Clients are pure renderers — they display whatever the server tells them.

This eliminates the host advantage because all players connect to the same neutral server with equal network conditions. A player in the same datacenter might have 5ms latency while a remote player has 80ms, but no player has the unfair 0ms advantage that the P2P host enjoys. The latency difference is a function of geography, not architecture.

The matchmaking system uses Redis sorted sets keyed by skill rating (MMR) to group players of similar ability. ZRANGEBYSCORE finds players within an MMR range in O(log N + M) time — approximately 2ms for 100K queued players. When enough players at similar skill levels accumulate, MatchService forms a match and publishes a match-created event to Kafka. AllocatorWorker consumes the event and provisions a dedicated GameWorker container (4 vCPU, 8 GB) for the match. The Kafka decoupling is essential because server provisioning takes 2-5 seconds — if MatchService waited synchronously, the matchmaking endpoint would time out.

After the match completes, GameWorker publishes results (per-player stats, XP earned, win/loss) to a separate ResultStream (Kafka). ProgressionWorker consumes results and updates player XP, rankings, and MMR in PlayerDB (PostgreSQL). This async pipeline means the player sees the match-complete screen immediately while progression updates settle in the background within 5 seconds.

The primary limitation of this architecture is the absence of client-side prediction. Pure server-authoritative without prediction means players feel full network round-trip delay (50-100ms) between pressing a button and seeing the result on screen. For casual games this is acceptable, but for competitive FPS games, 80ms of input lag makes the game feel sluggish. The Global variant (v2) solves this with rollback netcode — client-side prediction with server reconciliation — which makes the game feel responsive at up to 150ms RTT.

The second limitation is single-region deployment. Cross-continent players experience 100-200ms ping, making competitive play unfair based on geography. The Global variant deploys game servers in 5+ regions and routes players to their nearest region. This is the architecture interviewers expect candidates to build toward after establishing the single-region authoritative baseline.

The authoritative multiplayer game system uses 10 components organized into three logical layers: matchmaking and lobby (Client, API Gateway, Load Balancer, MatchService, SessionCache), game simulation (AllocatorWorker, GameWorker), and progression (ResultStream, ProgressionWorker, PlayerDB). Two Kafka streams decouple match formation from server allocation and match completion from progression updates.

All lobby and profile traffic enters through the API Gateway, which validates session tokens (~3ms), enforces rate limits (80K RPS), and routes /api/v1/* traffic to MainLB. The API Gateway handles authentication as a cross-cutting concern — GameWorker-bound UDP traffic bypasses it entirely. MainLB distributes requests across 10 MatchService pods using round-robin (matchmaking is stateless, with queue state in Redis).

MatchService is the core orchestrator. It handles four endpoints: (1) POST /api/v1/matchmaking/queue — add player to the matchmaking queue in SessionCache (Redis sorted set by MMR), wait for enough players at similar skill levels, form a match, publish match-created event to MatchStream; (2) GET /api/v1/matchmaking/status — poll for match assignment by reading session state from Redis (QUEUED/MATCHED/IN_GAME with server address); (3) GET /api/v1/players/{id}/profile — read player stats from PlayerDB with Redis cache; (4) POST /api/v1/matches/{id}/result — receive match results from GameWorker, publish to ResultStream.

SessionCache (Redis, 6-node cluster) stores the matchmaking queue as a sorted set, active session state (player to match mapping), and match server assignments. The sorted set enables O(log N) skill-based grouping. TTL of 300 seconds auto-evicts abandoned queue entries.

The game server provisioning pipeline is fully async. MatchStream (Kafka, 32 partitions) carries match-created events from MatchService to AllocatorWorker. AllocatorWorker (20 instances) provisions a dedicated GameWorker container per match, assigns an IP/port, and writes the server address back to SessionCache. Players discover their server via polling GET /api/v1/matchmaking/status.

GameWorker is the most resource-intensive component: one dedicated instance per active match running at 60 ticks per second. It receives player inputs via UDP, validates server-side (the core anti-cheat mechanism), simulates the game state, and broadcasts state snapshots. At 100K concurrent matches with 4 vCPU per match, the fleet requires 400K vCPUs — the dominant infrastructure cost. On match completion, GameWorker publishes results to ResultStream.

The progression pipeline processes match results asynchronously. ResultStream (Kafka, 32 partitions) carries match-ended events to ProgressionWorker (20 instances), which calculates XP, updates player levels and rankings in PlayerDB (PostgreSQL, 32 partitions, 3 replicas), and recalculates MMR using an ELO-style algorithm. Strong consistency on PlayerDB prevents double-awarding XP on retry.