Design an online multiplayer game backend

Never trust the client: if clients decide hits or positions, cheaters teleport and one-shot everyone. The server owns the truth and runs a fixed-step simulation (20-30 Hz for mobile battle royale, 60-128 Hz for competitive PC shooters). Waiting 60 ms for the server before moving your own character feels terrible, so the client predicts locally: it applies its own inputs immediately and keeps a buffer of unacknowledged inputs. When a snapshot arrives saying 'at input #812 you were at (x, y)', the client resets to that state and replays inputs 813 onwards (reconciliation); small errors are smoothed. Other players are rendered by interpolating between two received snapshots, about 100 ms behind. That creates a problem for shooting: you aim at where you saw the enemy, which is in the past. The server fixes this with lag compensation: it keeps ~1 s of position history per player, rewinds targets to the shooter's view time (estimated from RTT plus interpolation delay), checks the hit, then restores. Cap the rewind (~200 ms) so players with terrible ping cannot shoot people who already took cover. Use UDP with your own sequence numbers and acks: TCP head-of-line blocking would freeze the game on a single lost packet, while a lost snapshot is simply superseded by the next one.

Each ticket carries a party MMR (for example a Glicko/TrueSkill-style rating with an uncertainty), the mode and measured latencies to each region. Tickets are pooled per (region, mode) in Redis sorted sets keyed by MMR. A matchmaker loop runs every second per pool: take the oldest tickets first, collect tickets within an MMR window around them, and form a match when 100 slots fill while respecting party sizes. The window starts narrow (±50) and widens with wait time (±300 after 45 s); after ~60 s a ticket may also be offered a second region if its ping there is acceptable, or the match is filled with bots, which mobile games commonly do for low-rank players. Each pool is owned by one matchmaker worker (lease in Redis or etcd) so two workers never put the same ticket into two matches; formation uses an atomic 'claim tickets' step (Lua script or WATCH/MULTI) to be safe. Party tickets are atomic units. Measure what matters: p50/p90 queue time per region and rank band, and match quality (MMR spread, ping spread).

Starting a VM takes minutes, but players expect a match within seconds of being matched. So each region keeps a warm buffer of game server processes in the Ready state (for example 10-15% of current allocated count, larger before evening peak and festival events). Agones on Kubernetes is a common open-source choice; GameLift is the managed option on AWS. Allocation is an atomic state change from Ready to Allocated, so two matches never land on the same process. Scaling up adds nodes when the Ready buffer drops below target. Scaling down is the tricky part: you must never kill a node that hosts a running match. Nodes are cordoned, their Ready servers removed, and the node is deleted only when its last match ends (up to ~30 minutes). Pack matches onto fewer nodes (bin packing) so nodes empty out faster. Game servers run one match per process so a crash affects 100 players, not 1,000. Region placement follows players: Mumbai and Hyderabad cloud regions cover most of India with 20-50 ms RTT; very poor networks benefit from regional relays.

Match results drive real value (rank, items, sometimes paid rewards), so the path must be exactly-once in effect. The game server is the only source of results; clients never report their own kills. The server submits results with match_id and retries until acknowledged; consumers are idempotent because the ledger row has a unique key (player_id, reason, source_id) and leaderboard updates check a processed-match set. Inventory is an append-only ledger, not a mutable counter, which makes audits and refunds simple. Anti-cheat has layers: server-side validation every tick (movement speed, fire rate, line-of-sight), client integrity checks, and offline analysis of telemetry in ClickHouse to spot aimbots (inhuman reaction times, perfect tracking) and wallhacks (aiming at players behind walls). Bans are applied with a delay and in waves so cheat makers cannot easily tell which change got them caught. Reports from players feed the same pipeline.

Peer-to-peer with a host player is cheap and fine for 2-8 player casual games, but the host has a latency advantage, can cheat, and the match dies if they leave. For 100 players and competitive play, dedicated servers are the only option despite the hosting cost (roughly a few paise per player-hour: one 16-vCPU VM at under $1/hour hosts ~900 players).

Game state is time-sensitive; old snapshots are useless. UDP lets you drop and supersede instead of retransmitting. Important events (kill feed, inventory pickup) get selective reliability on top. WebSocket/TCP is acceptable for turn-based or slow games (Ludo, card games) and much simpler.

Higher tick rate means fairer hits but more CPU and bandwidth. 128 Hz costs about 5x the CPU of 25 Hz. For a mobile battle royale on Indian 4G, 20-30 Hz with good interpolation is the right balance; competitive 5v5 PC games justify 64-128 Hz with 10 players per server.

Tight MMR windows make fair games but long waits at high ranks and off-peak hours. A widening window plus bots for low ranks keeps queues short. Make it a per-pool configuration so designers can tune it.

Concurrency in India peaks around 8-11 pm and jumps when a new season launches. Pre-scale the fleet from a forecast an hour ahead, raise the warm buffer, and rate-limit login/matchmaking with a visible queue rather than letting the control plane collapse.

One popular mode in one region can get 1,000+ tickets/s. Shard the pool by MMR band (each band owned by one worker) and allow borrowing across adjacent bands as wait time grows.

When 40 players land in one town, snapshots grow. Interest management (send only nearby or visible entities, lower update rate for distant ones), quantised positions and delta compression keep packets under the MTU.

Running matches only need their game server process; they continue normally. Results are buffered on the game server (and local disk) and resubmitted when the results API recovers. New matchmaking pauses, which players notice, but no match is lost.

Affects one match (100 players). Detect via missed heartbeats, mark the match aborted, give players a 'match cancelled' notice and do not apply rank losses. Process-per-match isolation limits blast radius.

The server keeps the player's character in the world (vulnerable) for ~60-90 s. On reconnect, the client asks the control plane for its active match (from the matches table), gets a new join token and resumes with a full snapshot.

Matchmaking stops sending tickets to that region and offers players the next-best region by measured ping. Matches already in the region either finish or are cancelled without penalty.