Design Design PUBG

Problem Statement

Design the backend infrastructure for a battle royale game at PUBG scale. 100 players connect to a single game server, drop onto an 8km × 8km map, collect weapons and equipment, and fight in real-time combat while a shrinking zone forces encounters. The last player or squad standing wins.

Unlike traditional web systems, this is a real-time simulation problem. The server must process inputs, simulate physics, detect hits, and broadcast state to all players every 50 milliseconds (at 20 Hz tick rate). Latency is measured in frames, not seconds.

The system has two distinct halves: a platform layer (matchmaking, profiles, inventory — standard microservices) and a game server layer (real-time simulation — ephemeral, stateful, latency-critical). The architecture challenge is the bridge between them.

Requirements

Functional Requirements

Non-Functional Requirements

Scale Estimation

All numbers derived from assumptions, not pulled from thin air. Starting from 50M MAU (PUBG's peak scale).

API Design

APIs split into two categories: Platform APIs (REST/gRPC for matchmaking, profiles, inventory) and the Game Protocol (custom binary UDP for real-time state sync).

Platform APIs (REST over HTTPS)

POST /api/v1/matchmaking/queue
Authorization: Bearer <session_token>

{ "mode": "squad", "region": "ap-south-1", "map": "erangel", "perspective": "tpp" }

→ 202 Accepted
{ "ticket_id": "tkt_a8f3...", "estimated_wait_sec": 12, "status": "queued" }

GET /api/v1/matchmaking/ticket/{ticket_id}

→ 200 OK (when matched)
{
  "status": "matched",
  "match_id": "match_7bc2...",
  "game_server": {
    "host": "gs-ap-south-42.pubg.internal",
    "port": 7777, "udp_port": 7778,
    "token": "eyJhbG..."
  },
  "lobby_players": 97, "map": "erangel"
}

GET /api/v1/players/{player_id}/profile

→ 200 OK
{
  "player_id": "p_9d3f...", "username": "ShroudLite", "level": 47,
  "rank": { "tier": "platinum", "division": 2, "rating": 1847 },
  "lifetime_stats": {
    "matches_played": 3241, "wins": 186, "kills": 9720,
    "kd_ratio": 3.42, "avg_damage": 312.5
  }
}

Game Server Protocol (Real-Time, UDP)

Once matched, everything switches to a custom binary UDP protocol. REST doesn't work here — TCP's head-of-line blocking adds 100–300ms spikes on packet loss, and the server must broadcast state every 50ms.

High-Level Architecture

Two parallel worlds: an always-on platform layer (standard microservices) and an ephemeral game server layer (stateful simulation instances that live for one match). The bridge between them is the Game Server Orchestrator.

Regional Architecture

Each of 5–6 major regions is nearly self-contained: its own matchmaker, game server fleet, orchestrator, database replicas, and Kafka cluster. Players are matched within their region for latency. Only account/auth, shop/payments, and global leaderboards are truly global services synced asynchronously across regions.

Game Server Orchestrator

The most unique component — doesn't exist in typical web systems. Maintains a warm pool of pre-provisioned game server containers. When the matchmaker fills a lobby, it requests a server from the pool (< 2 seconds), avoiding cold-start delays. Pre-warming uses predictive scaling based on time-of-day and historical demand. At peak, the orchestrator recycles ~480 servers per minute.

Deep Dive — Real-Time Game Networking

Everything else in this design is standard distributed systems. The hard, novel problem is keeping 100 players in sync on an 8km map with sub-100ms perceived latency over unreliable networks. Four interlocking techniques make this work.

Client-Side Prediction — How It Works

Without prediction, pressing W results in 83ms of nothing (30ms to server + 3ms processing + 50ms back), then a sudden teleport. At 60 FPS, that's 5 frames of your character ignoring you. Unplayable.

With prediction: the client immediately applies your input to a local physics simulation — the same code the server runs. It stores each predicted result in a prediction buffer (ring buffer, ~128 entries = 2 seconds of inputs). When the server confirms input #N, the client discards entries up to N and re-simulates everything after N on top of the server's authoritative position.

The re-simulation typically processes 4–14 frames and takes < 0.1ms — invisible in the frame budget. When prediction matches (99% of the time), the player sees nothing. When it doesn't, the correction is blended over 50–200ms depending on error magnitude.

Lag Compensation — The Shot Sequence

          sequenceDiagram
              participant A as Player A (Shooter)
              participant S as Game Server
              participant B as Player B (Target)

              Note over A: Sees B at positionfrom 80ms ago
              A->>A: Click fire — muzzle flashplays instantly (prediction)
              A->>S: PLAYER_INPUT {fire, yaw, pitch, seq:47}
              Note over S: Receives after ~30ms
              S->>S: Calculate A's view timeT - 30ms - 50ms = T-80ms
              S->>S: Rewind B's hitbox to T-80ms
              S->>S: Raycast → HIT on B's torso
              S->>S: Apply 38 HP damage (AKM)
              S-->>A: HIT_CONFIRM {damage:38, zone:torso}
              S-->>B: DAMAGE_EVENT {from:A, dmg:38, dir:NW}
              Note over A: ~63ms total — sees hit marker
              Note over B: ~63ms total — takes damage,screen shakes
        

The server maintains a position history buffer for every player (last 1 second, 20 entries × ~40 bytes = 80 KB total). On a shot, it interpolates between the two history entries bracketing the shooter's view time, reconstructs hitboxes, and checks the ray. The rewind is capped at 250ms to prevent abuse from players intentionally adding latency.

The Peeker's Advantage — An Unavoidable Tradeoff

Because of lag compensation, the player who peeks a corner has a ~80ms advantage over the defender. The peeker sees the defender immediately, but the defender sees the peeker ~80ms late. This is a fundamental consequence of physics (speed of light + network latency) — there is no solution that eliminates it without breaking hit registration for the shooter. Every competitive FPS makes this same tradeoff.

The Tick Budget

At 20 Hz, the server has 50ms per tick to process everything:

Area of Interest (AOI) — Spatial Grid

The 8km × 8km map is divided into 500m × 500m cells (16 × 16 = 256 cells). Each player belongs to one cell. Their AOI = their cell + 8 neighbors (3×3 grid). Only entities within these 9 cells are included in their state update — cutting broadcast from 100 to ~20 players. Cell lookup is O(1) by hashing position to cell index.

Delta Compression — 60–80% Bandwidth Savings

Instead of sending full state every tick, the server tracks what each client has ACK'd and sends only changed fields. A field bitmask (1 byte) indicates which fields follow. If only position changed: 7 bytes instead of 19 bytes per entity. If nothing changed: 1 byte. Typical savings: ~82%.

Key Design Decisions & Tradeoffs

1. Server-Authoritative vs Client-Authoritative

2. Tick Rate — 20 Hz vs 60 Hz vs 128 Hz

3. UDP vs TCP for Game Traffic

4. Lag Compensation — Favor Shooter vs Favor Target

5. Game Server Lifecycle — Containers vs Bare Metal

6. AOI — Fixed Spatial Grid vs Quadtree

7. Anti-Cheat — Kernel-Level vs Server-Only

What Can Go Wrong

Interview Tips

Evolution

How this design grows from MVP to planet-scale.