Multiplayer Game Server — Naive (Client-Hosted P2P)

Designing a multiplayer game server is one of the most demanding system design interview questions because it combines real-time networking, state synchronization, anti-cheat concerns, and global infrastructure in a single problem. The naive client-hosted P2P approach is where every candidate should start — it establishes the baseline that makes the improvements in dedicated server architectures measurable and concrete.

The core challenge is enabling multiple players to interact in a shared game world in real-time. In the naive approach, one player (the host) runs the game simulation on their local machine. Other players connect directly to the host via UDP after finding each other through a simple lobby service. The lobby service is the only backend component — it stores lobby codes, player lists, and the host's IP address in a PostgreSQL database. Once the match starts, all game traffic is peer-to-peer and never touches the backend.

The P2P model's fatal flaw is the host advantage. The host player experiences zero network latency — their inputs are applied to the local simulation instantly. Other players experience full round-trip time (50-150ms) to the host, meaning they always react slower in close encounters. In competitive games, this asymmetry makes fair play impossible. A host with 0ms latency will win virtually every 50/50 engagement against a guest with 80ms latency.

The second critical flaw is the complete absence of anti-cheat. Since the host runs the game simulation, they can modify any game state — teleporting, invulnerability, aimbotting — without any server-side validation to detect or prevent it. Even non-host players can send forged inputs that the host may not validate. Production competitive games require server-authoritative simulation where no client is trusted, which is the approach taken by the Authoritative variant (v1).

The third flaw is host disconnection. If the host player crashes, rage-quits, or loses network connectivity, the match ends immediately for all players. There is no host migration in this naive approach — the game state exists only on the host's machine. Production P2P games implement host migration protocols, but these add significant complexity and still cause a 5-10 second interruption.

Despite these limitations, client-hosted P2P remains relevant for specific use cases: casual co-op games with trusted friends (e.g., Minecraft, Among Us early versions), LAN party play, and indie game prototypes where dedicated server infrastructure is not feasible. The architecture's simplicity — just 3 components — makes it the fastest path from zero to playable multiplayer.

This template makes the host advantage and anti-cheat gaps visible and quantifiable. Run the simulation and observe the latency asymmetry between host and guest players. Compare with the Authoritative variant to see how a neutral dedicated server eliminates the host advantage, and with the Global variant to see how regional servers and rollback netcode make competitive play fair across continents.

The naive multiplayer game system is a three-component architecture: PlayerClient, LobbyService, and LobbyDB (PostgreSQL). There is no dedicated game server, no cache, no event stream, no matchmaking algorithm, and no anti-cheat. The backend exists solely to coordinate lobby creation and joining — actual gameplay is entirely peer-to-peer.

All backend traffic flows through LobbyService, a stateless REST API running on 3 ECS Fargate pods with 50 threads each. It handles four operations: (1) lobby creation — generate a 6-character code, store host IP and game settings in LobbyDB, return the code for sharing; (2) lobby join — add a player to the lobby's participant list, return the host's IP address and current player list; (3) lobby polling — return the current lobby status (WAITING, IN_GAME, or EXPIRED) so joining players know when the host starts the match; (4) match start — transition the lobby status from WAITING to IN_GAME, triggered by the host player only.

LobbyDB is a single PostgreSQL instance storing lobby records. Each record contains the lobby code (primary key), host player ID, host IP address, game mode, max player count, current player list (JSONB), status, and creation timestamp. At 10K concurrent lobbies with approximately 200 bytes per record, the working set is under 2MB — trivially small. Lobbies expire after 300 seconds via a background cleanup job keyed on the created_at timestamp.

The gameplay data flow is entirely client-side. When the host starts the match, joining players detect the status change on their next poll (every 2 seconds) and initiate a direct UDP connection to the host's IP address. The host's game client runs the simulation at 30-60 Hz, receives inputs from connected players, applies game logic, and broadcasts state updates. All game state lives on the host's machine — the backend has zero visibility into what happens during a match.

The system has no redundancy at any layer. A single LobbyService deployment serves all lobbies. A single PostgreSQL primary handles all reads and writes. If either fails, new lobbies cannot be created and existing lobbies cannot be joined, but ongoing matches continue unaffected since they are P2P. This is one accidental benefit of the P2P model — backend outages do not interrupt active matches.

The concrete scaling ceiling is approximately 8K RPS at peak, limited by LobbyService capacity (3 pods x 50 threads x processing time). Since the backend only handles lobby coordination and not gameplay, the actual bottleneck is NAT traversal — many players behind symmetric NAT firewalls cannot accept incoming UDP connections, making them unable to host or connect. Production P2P games solve this with STUN/TURN servers, adding infrastructure complexity that this naive approach deliberately avoids.