Multiplayer Game Server — Global Competitive Platform

The global competitive platform architecture is the production-grade solution for multiplayer games operating at worldwide scale — the architecture behind League of Legends, Valorant, Fortnite, and Apex Legends. It solves the two critical limitations of the single-region authoritative approach: network latency perception and geographic unfairness.

The first problem is perceived input latency. In the single-region authoritative model (v1), players feel the full network round-trip time (50-100ms) between pressing a button and seeing the result on screen. For casual games this is acceptable, but for competitive FPS and fighting games, 80ms of input lag makes the game feel sluggish and unresponsive. Players describe it as 'playing through mud.' The global variant solves this with rollback netcode — a technique where the client predicts the outcome of local inputs immediately (applying them to a local simulation copy) and corrects when the server's authoritative state arrives. If the prediction was correct (which it is 90%+ of the time for movement), the player sees zero input lag. If the prediction was wrong, the client rolls back to the server state and replays subsequent inputs, causing a brief visual correction.

The second problem is geographic unfairness. A single-region deployment means players in Tokyo connecting to US-East servers experience 150-200ms RTT, while players in New York enjoy 10ms. This geographic lottery determines competitive outcomes more than skill. The global variant deploys game server fleets in 5+ regions (US-East, US-West, EU-West, AP-Northeast, AP-Southeast) and the matchmaking service routes players to their nearest region. Most players connect with sub-30ms ping, creating a level playing field regardless of continent.

Beyond latency optimization, the global platform adds several production-critical features. A dedicated anti-cheat service consumes sampled player inputs from a Kafka stream and performs statistical analysis — detecting impossible movement speeds, inhuman aim trajectories, and suspicious action timing. Unlike inline validation that must complete within the 16.67ms tick budget, the dedicated service can spend seconds on deep analysis and flag cheaters mid-match or post-match.

Every game state tick (60 per second per match) streams through Kafka, enabling two powerful features: live spectating (viewers subscribe to a match's state stream with approximately 2-second delay) and replay recording (the full tick stream is archived to S3 for post-match replay, highlights, and tournament review). At 150K concurrent matches, the game state stream handles 9 million events per second — requiring 256 Kafka partitions.

VoiceRelay handles real-time team voice communication. Instead of peer-to-peer voice (which creates O(N^2) connections in a team), a centralized relay mixes audio from all teammates into a single stream per player. Each player sends one audio stream and receives one mixed stream, adding approximately 20ms of latency — imperceptible for voice communication.

ProgressionService persists player data (XP, rankings, match history) to PostgreSQL with strong consistency. Match results flow through Kafka from the game server fleet, enabling async processing without blocking the match-end screen. The progression system supports leaderboards, seasonal rankings, and detailed match history with per-player stats.

This is the architecture interviewers at gaming companies expect senior candidates to describe. The progression from P2P to authoritative to global demonstrates deepening understanding of real-time systems, and the specific technical choices (rollback netcode, regional routing, Kafka streaming for replay) signal production experience with latency-sensitive distributed systems.

The global competitive platform uses 10 components organized into five functional areas: matchmaking (MatchmakingService, MatchmakingCache), game simulation (GameServerFleet), data streaming (GameStateStream, ReplayStore), player services (ProgressionService, ProgressionDB, VoiceRelay), and security (AntiCheatService). The architecture is designed for multi-region deployment, though the simulation models a single region.

All matchmaking and profile traffic enters through MatchmakingService (15 ECS Fargate pods, 100 threads each). Unlike the v1 architecture with API Gateway and Load Balancer, the global variant routes directly to specialized services for lower latency. MatchmakingService handles three endpoints: queue for matchmaking (writes to Redis sorted set partitioned by region), poll matchmaking status (reads from Redis), and get player profile (reads from ProgressionDB with Redis cache). When enough players at similar skill levels in the same region accumulate, MatchmakingService forms a match and directly allocates a GameServerFleet instance.

MatchmakingCache (Redis, 8-node cluster, 26 GB) stores regional matchmaking queues as sorted sets, active session state, and hot player profiles. Partitioning queues by region ensures matchmaking operates independently per region. The 60-second TTL on queue entries is shorter than v1's 300 seconds because the global system enables cross-region fallback after 60 seconds for sparse regions.

GameServerFleet is the fleet of dedicated game server instances — one per active match. Each instance runs the authoritative simulation at 60 Hz with rollback netcode support. The server maintains a rolling buffer of recent game states (typically 10-20 frames). When a client's predicted state diverges from the server's authoritative state, the server sends a correction. The client rolls back to the corrected state and replays all inputs since that state, producing a smooth visual correction rather than a jarring teleport. This technique makes the game feel responsive at up to 150ms RTT.

GameStateStream (Kafka, 256 partitions) is the central nervous system of the platform. It carries three topic types: (1) game-state-tick — every authoritative game state snapshot at 60 Hz per match, consumed by spectator delivery and replay archiver; (2) match-result — end-of-match results consumed by ProgressionService; (3) anticheat-input-stream — sampled player inputs consumed by AntiCheatService. At 150K concurrent matches, the stream handles 9M events/sec for game state ticks alone.

ReplayStore (S3) archives complete match replays. The replay archiver consumer reads game-state-tick events from Kafka and writes compressed replay files to S3. Each 10-minute match generates approximately 100MB of state data. S3 Standard storage with lifecycle policies transitions replays to S3 Glacier after 30 days. ProgressionService serves replay metadata and generates pre-signed S3 URLs for client download.

AntiCheatService (30 worker instances) consumes sampled input streams from Kafka and performs deep statistical analysis: movement speed anomaly detection, aim trajectory analysis (detecting inhuman flick patterns), action timing validation, and impossible state detection. Running asynchronously means analysis can take 1-5 seconds without affecting the game server's tick budget. Flagged players are kicked mid-match via callback to GameServerFleet.

ProgressionService (8 pods, 100 threads each) handles player progression and replay access. It consumes match-result events from Kafka, calculates XP, updates player levels and MMR in ProgressionDB (PostgreSQL, 64 partitions, 3 replicas), and writes match history records. It also serves profile reads, leaderboard queries, and replay metadata.

VoiceRelay (50 pods) handles team voice communication. Players send Opus-encoded audio packets via UDP, and VoiceRelay mixes audio from all teammates into a single outbound stream per player. Running in the same region as the game server ensures minimal added latency (~20ms). Audio is ephemeral and not persisted.