Gaming & realtime, an interactive architecture walkthrough
Multiplayer game backend: how the architecture works
How a multiplayer game backend matches players by skill and latency, runs each match on an authoritative server, and processes results afterwards.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A multiplayer game backend has two very different halves. Platform services, accounts, friends, parties, inventory and leaderboards, are ordinary web services over HTTPS and WebSockets. The match itself runs on a dedicated game server: one authoritative process per match that receives player inputs over UDP, simulates the game at a fixed tick rate and sends state back, while clients predict their own movement and correct it.
Matchmaking connects the two. Players queue as tickets with mode, region, latency and skill; a match function groups them into fair teams, widening the skill range as waiting time grows; and an allocator hands each match a warm server from a fleet scaled per region. When a match ends its results flow through an event stream to progression, skill ratings, leaderboards and analytics. This is a simplified learning design, not any studio's production system.
Trade-offs and what changes at scale
Authoritative servers prevent most cheating and keep players in sync but cost a server process per match, while peer-to-peer or relayed play is cheaper and easier to cheat. Stricter skill matching produces fairer games and longer queues, so the match function relaxes rules over time. Warm server pools cut wait times but pay for idle capacity. At larger scale the launch-day peak drives the design: fleets are spread across regions and cloud providers, and platform services are protected with queues and rate limits so a login storm does not take them down.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
The Game Client signs in through the Account Service, which links console, PC and mobile accounts and loads the profile and inventory from the Player DB. Everything outside a match goes through these ordinary HTTPS services.
The client keeps a WebSocket to the Realtime Gateway for invites and party chat, and the Social Service tracks parties and online status in the Presence Cache. A party of friends then queues as one unit.
Pressing play creates a matchmaking ticket with the party, game mode, region and measured latency, and the Matchmaker adds it to the Ticket Pool. Tickets wait there until a match function picks them.
The Match Function runs every second or so, groups tickets into fair teams using Skill Rating and latency, and widens the allowed skill gap the longer a ticket waits. Matching quality and waiting time are traded off explicitly here.
For each proposed match, the Server Allocator takes a warm server from the Fleet Manager in the right region and marks it allocated. Keeping idle servers ready means players do not wait for a machine to boot.
The Fleet Manager scales the pool of game server processes per region with demand and replaces unhealthy ones. During updates it never shuts down a server that is still hosting a match.
The Matchmaker sends the server address and a join token to every player through the Realtime Gateway. The token stops anyone not in the match from joining that server.
During the match, clients send inputs over UDP to the Game Server, which simulates the game at a fixed tick rate and sends state snapshots back. UDP is used because a late position update is worthless; the next one replaces it.
Because the server is authoritative, it rejects impossible movement or fire rates and reports patterns to Anti-cheat for review. Checks on the server cannot be bypassed by modifying the client.
When the match ends, the server publishes the result and match statistics to Match Events and is returned to the pool. Everything after the match is processed asynchronously, so a slow service does not hold the server.
The Progression Service grants XP and rewards in the Player DB, using the match id so a replayed event cannot grant rewards twice. Inventory changes are money-like, so they get the same care as payments.
Skill Rating updates each player's rating from the result, ranked results update Leaderboards, and the Analytics Store receives everything for balance and retention analysis. Ratings feed straight back into the next matchmaking round.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (19 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Platform Servicesdomain
- Account Service: login, device and platform accounts
- API Gateway: auth, rate limits
- Player DB: profiles, inventory, progression (postgresql)
- Presence Cache: online status and current party (redis)
- Realtime Gateway: party chat, invites, notifications (websocket)
- Social Service: friends, parties, presence
Playerslayer
- Game Client: renders, predicts, sends inputs
Matchmakingdomain
- Match Function: groups tickets by skill and latency
- Matchmaker: tickets in, matches out
- Skill Rating: updates player ratings after matches
- Ticket Pool: waiting tickets by mode and region (redis)
Dedicated Game Serversboundary
one process per match, many per machine
- Anti-cheat: server-side checks and reports
- Fleet Manager: keeps warm servers per region
- Game Server: authoritative simulation, fixed tick rate
- Server Allocator: assigns a ready server to a match
Results & Datadomain
- Analytics Store: balance, retention, cheating review (clickhouse)
- Leaderboards: ranked ladders (redis)
- Match Events: results, kills, economy events (kafka)
- Progression Service: XP, rewards, inventory changes
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
- googleforgames/agones: dedicated game servers on Kubernetes (fleets, lifecycle)
- Agones docs: Fleet updates (allocated servers are not shut down)
- googleforgames/open-match: matchmaking framework
- heroiclabs/nakama: game backend (accounts, social, parties, matchmaker, leaderboards)
- ValveSoftware/GameNetworkingSockets: reliable and unreliable messages over UDP
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Real-time leaderboardHow a real-time leaderboard ranks millions of players with in-memory sorted sets, takes scores only from game servers, and rolls boards over by season.
- Maps and navigationHow a maps system serves vector tiles from a CDN, routes over a preprocessed road graph with live traffic weights, and builds traffic from GPS traces.
- Ride-hailing platformHow a ride-hailing platform streams driver locations, matches a rider to a nearby driver, prices the trip with surge, and takes payment.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.