Design a Multiplayer Game Backend

Battle royale for 3 M concurrent players: 100-player matches on authoritative 30 Hz servers, fair hits, warm fleets and launch-day surges.

Last updated 2026-10-26. Difficulty: hard. Patterns: real-time, udp, game-servers, autoscaling, gaming. Reported at Epic Games, Riot Games, Activision, Electronic Arts, Roblox, Microsoft.

Functional requirements

• Log in and load the lobby. Account, profile, locker and friends in a couple of seconds. When demand is more than the backend can take, a waiting room with a real position and estimate, never a wall of errors.
• Friends, presence and parties. Parties of up to four. The party leader queues; matchmaking is an existing service that takes the party and hands back a formed match of 100 players and a region.
• Start each match on a dedicated server within seconds. From match formed to every client connected in under 10 s: a server process in the chosen region, on the players’ build, already running.
• Real-time movement, building and shooting for 100 players. Your own movement responds on the next frame, other players move smoothly, and the server decides every hit, judged as the shooter saw it.
• Matches of up to 25 minutes. The map shrinks until one player or squad is left. Eliminated players leave early and can queue again at once, so a match empties as it goes.
• Rewards, stats and inventory after each match. XP, battle pass progress, quests, lifetime stats and item grants, applied exactly once per player per match and visible in the lobby within seconds of being eliminated.
• Store and wallet. Buy currency with real money through the platform stores and spend it on items. A purchase debits and grants atomically, exactly once, and a refund reverses it.
• Cheat resistance. The server rejects impossible inputs and never sends a player what they should not know. Client anti-cheat and statistical detection feed bans.
• Out of scope. Matchmaking internals (see Design a Matchmaking System), leaderboards (see Design a Real-Time Leaderboard), voice chat, rendering and game design, patch downloads to clients, and the internals of the anti-cheat driver.

Non-functional requirements

• Scale (3 M concurrent players · 30 k matches). Peaks follow the evening in each region. A season start or a big launch brings 2–3× the usual peak inside an hour, most of it in the first ten minutes.
• Responsiveness (own input next frame · RTT < 80 ms). Prediction hides the round trip for your own movement. Matchmaking keeps every player under ~80 ms to the region, and the 30 Hz tick adds up to 33 ms before an input is simulated.
• Fair hit detection (server decides · rewind ≤ 200 ms). This is the requirement that drives the hardest trade-off: players disagree about where everyone was, and one view has to win. Favouring the shooter, within a cap, is the choice.
• Bandwidth per player (~15 KB/s down · ~2.4 KB/s up). Has to fit poor home and mobile connections, and sets the egress bill: ~54 MB per player-hour and ~360 Gbps across the fleet at peak.
• Match start (allocation p99 < 2 s · all connected < 10 s). Players will not wait minutes for a machine to boot. Capacity must already be running in every region: allocation picks a warm server, it never creates one.
• Match reliability (< 1 in 1 000 matches lost). A crashed match is lost, not failed over. State changes 30 times a second, and replicating it costs more than the rare loss, so crashes are kept rare and compensated.
• Correct progression and money (rewards exactly once · purchases atomic). A result applies once per (match, player) however often it is delivered, and a purchase debits and grants in one transaction. A retry never mints currency.
• Live services (99.95 % · degrade, don’t fall over). Under a surge, logins wait at a fixed admission rate rather than letting retries take down the profile database. A match in progress never depends on the backend.

Back-of-envelope estimates

• Concurrent matches: ~30 k. 3 M concurrent ÷ 100 per match = 30 k. Two effects roughly cancel: about 10 % of players are in the lobby or the queue at any moment, while eliminated players leave early, so a running match averages fewer than 100 people. Plan on 30 k.
• Match starts per second: ~20/s · ~50/s at a season start. 30 k concurrent ÷ 1 500 s (25 minutes) = 20 matches/s, so 2 k players/s are placed on servers. Each of them later produces exactly one result, so the post-match pipeline writes ~2 k results/s. A season start reaches ~50 starts/s, paced by the login queue.
• Downstream per player: ~15 KB/s (~120 kbps). Interest management keeps a snapshot to the ~40 entities near you, and delta compression against the last snapshot you acknowledged leaves ~12 B per moving entity. ~40 × 12 B plus headers and events ≈ 500 B, × 30 Hz = 15 KB/s. Without either, the full state of 100 players is ~4 KB a tick (120 KB/s) and does not fit in one packet.
• Upstream per player: ~2.4 KB/s. An input packet is ~50 B of payload (sequence, acks, buttons, view angles, and the previous two inputs again in case of loss) plus 28 B of UDP/IP headers ≈ 80 B, × 30 a second = 2.4 KB/s. Clients send intent, never positions, so upstream stays tiny.
• Game server hosts at peak: ~1 500 (20 matches each). A match’s game loop is mostly single-threaded and needs about one core at its busiest (the landing, the final circles) plus ~2 GB of memory. A 32-core host runs ~20 matches and keeps the rest for networking and spikes: 30 k ÷ 20 = 1 500 hosts, plus the warm buffer.
• Egress per host: ~240 Mbps · ~360 Gbps fleet-wide. 100 players × 15 KB/s = 1.5 MB/s = 12 Mbps per match; × 20 matches = 240 Mbps per host, a few percent of a 10 Gbps NIC. Fleet-wide, 3 M × 120 kbps ≈ 360 Gbps. Packets bind before bits do: 20 × 100 × 30 = 60 k packets/s out of each host, and as many in.
• Warm buffer of ready servers: ~3.6 k (~12 % of the fleet). Bringing a new host into service takes ~3 minutes, so ready processes must cover the starts in the meantime: 20 starts/s × 180 s ≈ 3 600 servers across ~10 regions, ~12 % on top of 30 k. A season start is covered by raising capacity ahead of time, not by this buffer alone.
• Logins at a season start: ~5 k/s · ~50 k/s with retries. 3 M players opening the game within ~10 minutes = 5 k/s, against ~550/s on a normal evening (3 M sessions of ~90 minutes). Clients retrying every few seconds turn that into ~50 k/s of attempts. Each login reads a ~50 KB profile, so 5 k/s is ~250 MB/s from the player store. This, not the game servers, is what falls over first.

Components

• Login queue (waiting room): The front door during surges. Admits logins at a rate the backend has shown it can take and gives everyone else a signed ticket with a position and an estimated wait. The admission rate is a control loop on backend health, so neither demand nor retries can push load past it.
• Waiting-room state (Redis · two counters): Per region, the next ticket number (INCR on join) and the admitted watermark the admission controller advances by R each second. A position is ticket minus watermark, so the queue costs O(1) per player whatever its length. Tickets are signed and carry their number, so losing this store loses no one’s place.
• Platform gateway (sessions · WebSocket): Trades an admission token and a platform credential for a session, authenticates every lobby call and routes it to the live services. Holds one WebSocket per online player for party invites, presence and match.ready pushes. Nothing on a match’s real-time path goes through it.
• Store & wallet (transactional · ledger): Sells items for currency and currency for real money. Spending is one transaction on the player’s shard: insert the client’s purchase id (unique), append a debit to the wallet ledger if the balance covers it, insert the entitlement. Real-money credits are unique on the platform’s transaction id, and refunds post reversing entries.
• Payment platforms (console stores · PSP): PlayStation, Xbox, Nintendo, Apple, Google, Steam, and a card provider for direct sales. Each returns a signed receipt or a server-side purchase record we verify before crediting currency, and each sends its own refund and chargeback notifications that we must consume.
• Game client (predicts · interpolates): Samples input every frame and sends it to the game server 30 times a second over UDP. Predicts its own movement at once and reconciles against the server’s answer, and draws everyone else ~100 ms in the past, interpolating between snapshots. Runs the client anti-cheat, whose session token is required to join a match.
• Friends & parties (presence · party state): Friends lists, presence and parties. Presence is pushed only on state changes (online, in a match, back in the lobby), ~4 k/s, while details such as players left are read when someone opens the list. The party leader’s queue request goes from here to matchmaking with the whole roster, and the party survives a lost match because it never lived on the game server.
• Matchmaking (existing service): The existing matchmaking service (see Design a Matchmaking System), not designed here. Takes a party’s ticket, forms a 100-player match in a region chosen by measured latency, asks the allocator for a server, and pushes match.ready with the address and join tokens through the gateway.
• Profile service (account · progression · items): Owns the account (credentials check, bans), progression (XP, level, battle pass tier, quests), lifetime stats and the item inventory. Read once at login for the lobby, written mostly by the post-match pipeline, one transaction per result. Never called by a game server during a match.
• Player data store (sharded by account id): Accounts, profiles, inventory, the wallet ledger and the applied-results table, all keyed by account id on the same shard, so a reward or a purchase is a single-shard transaction. A sharded relational store (MySQL with Vitess, or Postgres) gives the unique constraints idempotency needs. A profile is ~50 KB, read once per login.
• Game server (authoritative · 30 Hz · UDP): One process per match, holding the whole match in memory. Every 33 ms it applies the inputs that arrived, simulates movement, building and damage, and sends each player a delta-compressed snapshot of only what is relevant to them. Validates every input, lag-compensates hits by rewinding hitboxes, and writes nothing to the backend until a player’s match ends.
• Regional fleets (Agones on Kubernetes): A few clusters per region, ~20 game server processes per host, each a pod with its own UDP port. Keeps a buffer of Ready servers that the forecast raises before peaks, bursts into cloud capacity when owned hosts run out, and never removes an Allocated server, which is how a build update drains: old servers finish their match and exit.
• Server allocator (match registry): Turns a formed match into a running server in about a second. Picks a cluster in the requested region with Ready servers on the right build, allocates one through that cluster’s fleet, and records the match (id, roster, server, start time, state) with a signed join token per player. Watches server health so a crash becomes a match.aborted event, not silence.
• Post-match pipeline (idempotent on (match, player)): Consumes results, checks each against the match’s roster and the playlist’s caps, and applies XP, quest progress, stats and item grants through the profile service in one transaction guarded by a unique (match id, account id) row. Turns match.aborted into time-played compensation. Leaderboards and anti-cheat analytics read the same topic as separate consumers.
• Results queue (Kafka · key = account id): The durable buffer between game servers and the backend. match.results holds one record per (match, player), a result when that player’s match ends or a match.aborted from the allocator, keyed by account id so a player’s records apply in order; match.events holds match.started with the roster, keyed by match id. Retains days, so a profile store outage delays rewards but never loses them.

User flows

1. Match formed to first tick. Matchmaking hands over 100 players and a region; within seconds a warm server there is allocated, learns its roster, and every client is connected over UDP with a token. Nothing boots on this path.
   1. The party leader presses play; the friends service hands the whole party to matchmaking. The party is the unit: four friends become one matchmaking ticket and land on the same team. The client’s build version goes with it, because a match can only run on a server of the same build.
   2. Matchmaking forms a 100-player match in a region and asks the allocator for a server. Matchmaking’s job ends at a roster and a region chosen by measured latency. The call is idempotent on match id: a timeout and retry here would otherwise take two servers and split the roster.
   3. The allocator picks a cluster in that region with Ready servers on the build and allocates one. Allocation is a state change on a process that is already running with the map loaded, so it takes milliseconds to a second, not minutes. If the region’s clusters have no Ready server, the allocator tells matchmaking to hold the match for a few seconds rather than send it to a distant region.
   4. The allocator records the match in its registry and signs a join token for each player. The registry is what later tells a crash apart from a normal end, and which players to compensate. The game server verifies tokens itself with the allocator’s public key, so connecting needs no backend call.
   5. The game server learns it was allocated, reads its roster and opens a 60-second connect window. The process started minutes earlier, loaded the map and called Ready(). It sees the allocation through the SDK’s watch on its own record. Players who have not connected when the window closes are dropped from the roster and the match starts without them.
   6. Matchmaking pushes match.ready to every player through the gateway socket. All 100 should hear within a second: the bus leaves on a timer, and a player who connects late lands late. The push uses the socket the client already holds for party and presence, so there is no polling.
   7. Each client connects over UDP with its token; the server checks the token and the anti-cheat session. The challenge round trip means a packet from a spoofed address never gets a session, which matters because every player in the match learns the server’s address. From here on, client and server exchange 30 packets a second each way, encrypted with the session key.
   8. When everyone is in or the window closes, the match starts and the allocator publishes match.started. Formed to first tick in under 10 s: about a second to allocate, a second to push, a few seconds for clients to connect. Every one of those seconds is waiting on a network, never on a machine booting. match.started carries the roster, which the post-match pipeline uses to validate results later.
2. One tick: move, shoot, hit. The real-time core. Inputs go up 30 times a second, the server simulates, judges a shot as the shooter saw it, and sends each player only what is near them, encoded against what they last acknowledged.
   1. The client samples input, applies it locally at once, and sends it with a sequence number. The client never sends a position, only what was pressed and where the player is looking. It runs the same movement code as the server, so its prediction is almost always what the server will compute.
   2. Server tick: apply every input received since the last tick, after validating it, and simulate. Movement axes are clamped to [-1, 1], turn rate to what a hand can do, firing to the weapon’s rate and ammo; a connection sending 3× the expected packet rate is throttled and flagged. All 100 players must be simulated inside the 33 ms budget, so the target is ~15 ms on average, leaving room for the landing and the final fights.
   3. A fire input arrives: the server rewinds the other players’ hitboxes to what the shooter saw and traces the shot. View time = now − the shooter’s latency − their interpolation delay, the method Valve documents for the Source engine. The server keeps ~1 s of hitbox history (30 ticks × 100 players, ~600 KB), rewinds only players near the line of fire, traces, and restores them. Rewind is capped at 200 ms, so a player on a 300 ms connection must lead targets instead of hitting players who are long gone.
   4. The server sends each client a snapshot of what is relevant to it, as a delta against its last acknowledged snapshot. Relevance comes from a spatial grid: what is in nearby cells, your squad wherever they are, anything shooting at you. Entities are ranked by distance and staleness and the packet is filled to a ~1 200 B budget, so distant players update at 5 to 10 Hz instead of 30. Events that must arrive (eliminations, pickups, the storm moving) ride a reliable channel inside the same packets until acknowledged.
   5. The client reconciles: it resets its own player to the server state at last_input and replays the inputs after it. If the server agreed, the replay lands where the player already is and nothing visible happens. A small disagreement is blended away over ~100 ms; a large one, such as being blocked by a wall someone built a moment ago, is a visible snap, rare by design.
   6. The client draws other players 100 ms in the past, interpolating between the snapshots around that time. Three snapshots of buffer at 30 Hz means one lost packet causes no stutter. The cost is that what you see of an opponent is ~150 ms old (their half of the trip, a tick, your half, the buffer), which is exactly why the server has to rewind when you shoot.
   7. The hit is confirmed in the next snapshot, and the victim’s client learns of it in the same tick. The shooter’s client may play a hit effect at once, but health changes only on the server’s word. The fairness cost lands on the victim, who may already be behind a wall on their own screen when the hit arrives; the rewind cap is what bounds it.
3. Season launch: 3 M players at once. The scale-breaking case: demand arrives in minutes, not hours. Capacity is raised ahead from a forecast, logins wait in a queue at a rate the backend can take, and the first big purchase, the new battle pass, stays a single transaction.
   1. Hours before, the forecast raises each region’s fleet minimums and the new build is pre-pulled onto every host. Reactive scaling cannot meet a 2–3× peak that arrives in ten minutes when a host takes three to bring into service. The forecast starts from the same weekday’s curve per region, scales it by the factor seen at past launches, and requests burst capacity from the cloud provider days ahead, since everyone launching on the same morning can exhaust an instance type.
   2. Clients open the game; login is past its admission rate, so each gets a signed ticket and a position. A visible queue replaces 3 M clients each retrying every few seconds, which would put ~50 k requests a second on services sized for 5 k. Polls back off with position and are answered from a watermark each queue node caches, so millions of waiting players cost almost nothing.
   3. An admission controller advances the watermark each second, and a ticket below it is exchanged for an admission token. Additive increase, multiplicative decrease on admissions: the rate climbs while the backend is healthy and halves the moment it is not, so a struggling database slows the queue instead of failing logins already under way. It starts low (~2 k/s) while caches are cold after the season change.
   4. The admitted client logs in at the gateway, which checks the account and issues a session. The gateway checks the admission token’s signature locally. One login reads the account and a ~50 KB profile; at 5 k admissions a second that is ~250 MB/s from the player store, which is exactly the load the admission rate protects.
   5. The lobby loads: profile, locker, friends and presence, in one aggregated call. Presence is the first thing to shed under load: if the friends service is slow, the lobby renders without it rather than waiting. A lobby in two seconds matters more than a complete friends list.
   6. The player buys the new battle pass with currency: one transaction debits the wallet and grants the pass. BEGIN; insert the purchase id (unique); append a −950 ledger entry if the balance covers it; insert the entitlement; COMMIT, all on the player’s shard. A retry after a timeout hits the unique purchase id and returns the first result, so a flaky connection can never buy twice or pay without receiving.
   7. Another player tops up currency with real money; the store verifies the platform receipt and credits it once. The platform has already taken the money; our job is to credit exactly once and to reverse the credit when the platform later reports a refund or chargeback. A receipt that fails verification is kept for review rather than dropped, because a bug here costs real customers real money.
   8. Players queue, and the warm buffer absorbs the wave of allocations. The admission rate also paces the fleet: 5 k players admitted a second become at most ~50 match starts a second a few minutes later. If a region’s buffer still runs dry, matches wait in matchmaking for seconds with a visible message instead of going to a far region at 150 ms.
4. Game server crashes mid-match. The failure path. The match dies with its process, by design. What matters is noticing within seconds, getting players back to the lobby with their party, and compensating exactly once.
   1. A game server process crashes 14 minutes in, with 41 players still alive. Usually it is one process, not the host: the other 19 matches on that host carry on, each in its own process on its own port. If the host itself dies, all 20 fail at once and the same path runs 20 times.
   2. Clients stop receiving snapshots and, after a few seconds of retrying, show “connection lost”. A client cannot tell a dead server from its own dead router, so it keeps sending to the same address for ~5 s first: a brief network blip must not end anyone’s match. Then it asks the gateway what happened.
   3. The allocator sees the server go Unhealthy, marks the match aborted, and publishes match.aborted for each player still in it. The 59 players eliminated earlier already have their results written, because a result is written when each player’s match ends, not when the server’s does. Only the 41 still alive get an aborted record.
   4. Clients ask the gateway, learn the match is gone, and return to the lobby with their party intact. The party lives in the friends service, not on the game server, so the squad is still together and can queue again at once. A clear message and a fast way back matter more to players than the lost match.
   5. The post-match pipeline turns each aborted record into compensation: XP for minutes played, no stats, no placement. Minutes played times the playlist’s average XP rate feels fair and is never better than playing well. Quest progress from the lost match is not credited: it was never written, and inventing it would be easy to abuse. Compensation is capped per account per day.
   6. The fleet replaces the capacity, and the crash is counted against the build’s crash budget. Matches lost to crashes are a measured budget, under 1 in 1 000. A new build whose crash rate is above the old one’s halts its own rollout automatically, which is far cheaper than any amount of replication.
5. Match ends: rewards written once. The asynchronous path. Each player’s result leaves the game server once, when their match ends, travels through a durable queue, and is applied exactly once to progression, stats and inventory, even when everything in between retries.
   1. A player is eliminated in 37th place; the server finalises their result from counters it kept in memory. Time alive, eliminations, damage, chests opened and quest counters have been counted in memory all match. Nothing was written during play, so the backend saw no writes for this player for 14 minutes.
   2. The server publishes a signed result keyed by account id and keeps it until the broker acknowledges. Keyed by account id so all of one player’s results apply in order on one partition. The result is signed with the server’s fleet-issued identity, so a result from anywhere else is rejected.
   3. The pipeline checks the result: the player was on this match’s roster, and the numbers are within the playlist’s caps. The roster comes from match.started on the same queue. This is the backend’s own anti-cheat boundary: even a compromised game server cannot grant rewards to accounts that were not in its match, or more XP than a match can earn. Rejected results go to a review queue, not the floor.
   4. The profile service applies the result in one transaction, guarded by a unique (match id, account id) row. The unique row turns at-least-once delivery into exactly-once effects: a redelivered or replayed result inserts nothing and changes nothing. Level and battle pass tier are derived from total XP inside the transaction, so results applied in any order land on the same profile.
   5. The pipeline commits its offset only after the transaction commits. In that order, a crash between the two causes a duplicate, never a loss, and the unique row makes the duplicate harmless. Committing the offset first would make the same crash lose a reward silently.
   6. The player, already back in the lobby, sees their XP and battle pass progress within seconds. If the profile store is degraded, results wait in the queue, retained for days, and players see “rewards pending” for minutes instead of losing anything. Game servers are unaffected: they let go of the result at the broker’s acknowledgement.
   7. When the match ends, the server shuts down; the fleet replaces it with a fresh Ready process. A server never takes a second match: a fresh process means nothing leaks from one match to the next. During a build rollout this is also the drain: finished servers are replaced on the new build, so the fleet changes version within one match length without ending a single match.

Deep dives

The theory behind it

• Multiplayer game servers: How real-time multiplayer games keep players in sync: authoritative servers, tick rates and snapshots, client prediction and reconciliation, lag compensation, UDP networking, interest management, server allocation and fleets, persistence, cheating and scaling to large worlds.
• Autoscaling and capacity planning: Horizontal versus vertical scaling, what to autoscale on, why autoscaling is too slow for spikes, warm pools and pre-scaling, serverless trade-offs, headroom, and how to plan capacity from numbers.
• Stateful vs stateless services: Why stateless services scale and recover easily, where state has to live instead (databases, caches, sessions, object storage), and how to run genuinely stateful services such as WebSocket gateways, game servers, caches and stream processors with sticky routing, partitioning, replication and draining.

Related

• Design Slack
• Design a Matchmaking System
• Design LeetCode
• Design an Online Auction
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit