One day my nephew asked me:
Mama, you work on games, right? How would you design Call of Duty and PUBG–kind of games?”
(In our family I am Mama— uncle.)
He expected a short answer — maps, guns, graphics, maybe a cool explosion.
I almost said “it’s complicated.” Then I realized he had asked the right question for an architect not how the game looks, but how the system is arranged so players can find a match, stay in sync, and not melt the servers when a whole country logs in after school.
So I answered him the way I wish more design conversations started — with a map.
Not Erangel. Not Verdansk.
A map of regions, zones, and services.
This article is that answer. It is not a leak of PUBG’s or Activision’s private blueprints. Those backends are not fully public. It is how PUBG-like battle royale and Call of Duty–like multiplayer systems are typically shaped — the same vocabulary we use when we design high-scale live games: where the player lands, where the match runs, and which services do the work.
Draw the map before you name a tool.
| Layer | Plain meaning | Design rule |
|---|---|---|
| Region | Geography for ping, friends, and often data rules (India, EU, US-East…) | Matchmaking pools and “who can play with whom” are usually region-scoped |
| Zone | Capacity and failure slice inside a region (AZ / cluster / pod group) | A zone can die without killing the whole region; matches drain carefully |
| Service | A job the software must do (matchmaking, dedicated game host, store, anti-cheat) | Put each job where latency and ownership demand — not where the slide looks busy |
Mama’s rule: Players don’t talk to “PUBG” or “CoD.” They talk to a region. Matches run in a zone. Work is done by services.
If you cannot place a component on that map, you are not designing yet. You are collecting logos.
Naming trap — three different “zones”
Kids (and engineers) mix these up:
1. Cloud / infra zone — failure domain and capacity (this article’s “Zone”)
2. Map / safe zone — the shrinking circle in a battle royale
3. Interest / AOI zone — which other players and objects your client needs to know about right now
Same English word. Three layers. Keep them separate or the design review becomes comedy.
Walk one player from the sofa to the victory screen.
Here is the journey I walked with him — overlaid on the map.
1. Launch / login → hits platform services (identity, entitlement). Often multi-region capable, with a home region.
2. Lobby / party → region-aware presence: you queue with friends who share a sensible ping story.
3. Matchmaking → region-scoped queues (skill, playlist, fill rules). Output: “here is your match” + where to connect.
4. Connect to the match → client is steered to a dedicated game host (or relay path) sitting in a zone inside that region.
5. In match → authoritative simulation ticks; state replication; interest management; voice often match- or region-local.
6. Match end → results hand off to progression / inventory / battle pass (platform path — not on every bullet).
7. Side planes (always on) → anti-cheat signals, telemetry, crash reports — async, must not block the tick.
This is the same shape as systems I have lived with in live gaming
matchmaking as a door (ask and get placed), then a live channel / dedicated path as the room (stay connected for the session). Different genre. Same map logic.
What sits where — service placement.
| Service | Typical place on the map | Why |
|---|---|---|
| Identity / account | Platform (multi-region or hub + cache) | Shared identity; not every shot |
| Store / battle pass / inventory | Platform | Money and catalog; after or beside the match |
| Friends / party / presence | Region-aware | Parties hate cross-ocean ping |
| Matchmaking | Region | Pool quality + latency |
| Dedicated game servers / match instances | Zone inside region | Blast radius; capacity; drain on failure |
| Real-time game gateway / relay | Edge / region | Low latency into the match |
| Voice | Match- or region-local | Latency and moderation scope |
| Anti-cheat (client + server signals) | Match-local collect → hub aggregate | Hot path light; intel can be global |
| Telemetry / analytics | Side plane → lake | Never block the tick |
| Content / config catalog | Hub + CDN | Versioned rules, maps, playlists |
Hot path rule: bullets, movement, and tick authority stay near the player (region / zone). Store, heavy CRM, and batch analytics do not sit on the shot path — same lesson as handing wallet work off a live game loop.
Same map — different match shape (PUBG-like vs CoD-like)
I did not crown a winner. Both sit on Region → Zone → Services. The match they host looks different, so the fleet math changes.
| Concern | PUBG-like battle royale | CoD-like multiplayer modes |
|---|---|---|
| Match shape | Large map, many players, longer session | Smaller maps, shorter matches, many playlists |
| Dedicated fleet | Fewer, heavier matches per host | Higher match churn; faster spin-up / teardown |
| In-match pressure | Wide map + vehicles + loot; strong AOI needed | Tighter spaces; higher tick / precision pressure |
| Region pressure | Launch and country spikes; fill 80–100 seats | Playlist and seasonal spikes; many small rooms |
| What stays identical | Region routing, zone isolation, platform vs game split, async side planes | Same |
And, not vs: PUBG-kind and CoD-kind games are not rival architectures. They are two workloads on one map.
Region design — what my nephew already understood as “ping”
Ping budget decides who can share a match comfortably.
Party constraints beat “perfect MMR” if the squad cannot hear each other in time.
Empty lobby risk — a region that is too fine-grained never fills; too coarse and someone plays on 180 ms.
Data and policy — some player data and commerce prefer staying in-region.
Spill / overflow— when a region is on fire, you need a written rule (queue, wait, or rare cross-region with honesty about ping).
Region is a product decision as much as a cloud dropdown.
Zone design — why we don’t put every match in one basket
Inside a region, zones exist so that:
Hardware or AZ failure takes some capacity, not all evening matches
You can drain live matches (finish or migrate carefully) instead of hard-killing everyone
You scale dedicated fleets in slices — warm pools, playlist packs, BR vs small-modes packing
If matchmaking returns a host, that host’s zone is part of the placement decision — not an afterthought for Ops.
In-match: who owns the truth
For both genres, the dedicated (or authoritative) simulation owns match truth: positions, damage, win conditions. Clients predict for feel; server corrects for fairness.
That is the same ownership lesson as a live game table :many concerns in flight (inputs, timers, broadcasts), but one clear writer of shared state beats “a thread per player mutating the pot.” Concurrency is required. Chaos is optional.
Interest management (AOI) decides what to send whom — critical on a big BR map, still important in tight CoD lanes. That is game zoning, not your cloud zone.
“One contest, a million players” — how scale actually works
This is the question my nephew asked next: if a big contest has millions of players, do you build one giant server? When people die, do servers shrink? How does one website send everyone to the right place?
First correction — millions are not one match
A PUBG-like battle royale match is on the order of 100 players (squads fill seats). A CoD-like mode is often fewer per room.
A million concurrent players means roughly:
many regions taking traffic
huge matchmaking queues
thousands / tens of thousands of matches in parallel
each match on a dedicated host (or a packed host running N matches) inside a zone
So the platform scales by creating many small rooms, not by stuffing a million people into one simulation. One match still has one authoritative world. Parallelism across the system is many matches at once the same idea as many live tables running together.
Scale up — when the lobby catches fire
Autoscaling is driven by signals, not vibes:
| Signal | What scales up |
|---|---|
| Login / store spike | Platform pods / gateway capacity |
| Queue depth / wait time | Matchmaking workers + dedicated game fleet |
| Assigned matches with no free host | Warm pool → cold start more game servers in the zone |
| Telemetry / anti-cheat volume | Side-plane consumers (async) |
Typical dedicated-fleet pattern:
1. Keep a warm pool of ready game hosts per region/zone (already loaded build, waiting).
2. Matchmaking fills a lobby → allocates a host (or a match slot on a packed host) → returns connection info to clients.
3. If warm pool is empty and queue is deep → scale out more hosts (VM/container/bare metal — product choice).
4. Cap scale with max so a bug cannot bankrupt you; spill to “queue longer” rather than infinite machines.
Platform and matchmaking scale on HTTP/API metrics. The game fleet scales on matches needing a home.
Scale down — when the game finishes (not when one player dies)
When a match ends:
1. Dedicated host writes results → hands off to progression / rewards (platform).
2. Players disconnect from that match path.
3. Host is recycled (back to warm pool) or terminated if pool is fat.
4. Autoscaler watches idle hosts + queue depth → scale in slowly (hysteresis), so a two-minute lull does not thrash.
Important: when players are eliminated mid-match (“next circle, fewer alive”), you usually do not tear down or resize away the dedicated server. The match is still live until a winner (or draw) is declared. What can drop is work inside the match:
fewer clients to replicate to
lighter AOI / bandwidth
fewer voice peers
The map safe zone shrinks (game rules). The cloud zone fleet shrinks when matches complete and demand falls — different clocks.
Eliminated players often return to lobby / spectate / platform that traffic moves back to lobby and platform services, while the match host keeps serving survivors.
One domain — how everyone reaches the right service
Players remember one name: `play.example.com` or the game client’s embedded API host. Behind that single domain:
Client
→ DNS (often geo / latency aware) → regional edge
→ API gateway / load balancer
├─ /auth /store /profile → Platform services
├─ /party /presence → Region-aware social
├─ /matchmaking → Matchmaking
└─ after “match found”
→ dedicated host or game gateway
(host:port / token / session from matchmaking — not the store URL)(host:port / token / session from matchmaking — not the store URL)
So:
One public front door (domain + gateway) for lobby and platform.
Matchmaking is the redirector in product terms— it tells the client which game service/host owns this match.
In-match traffic often goes straight to the assigned game endpoint (UDP/dedicated), not through the store cluster.
Sticky cookies / tokens / session tickets bind “this player → this match host” for the life of the session.
That is the same door then room idea: REST (or similar) to get placed; persistent/realtime path to play.
What “services change” as the match levels up
| Moment | What changes |
|---|---|
| Queuing | Matchmaking + platform busy; game fleet warming |
| Match start | One host owns that match; clients leave matchmaking hot path |
| Players eliminated / circle shrinks | Game rules + AOI load change; dedicated host stays |
| Match over | Host frees; progression spikes briefly; fleet can scale down |
| Contest evening ends | Queue collapses → scale in matchmaking and game fleet toward baseline |
Services do not randomly morph mid-bullet. Ownership moves along the journey: platform → matchmaking → dedicated match → platform again. Autoscaling follows which layer is busy, match by match, region by region.
What not to put on the map’s hot path
Charging a card on every elimination
Synchronous “call the data warehouse” mid-fight
Treating matchmaking REST polls as the game loop
One global region “because simpler”
One mega-zone “because Kubernetes”
Draw the map. Then pick UDP, dedicated hosts, queues, and stores into the boxes — not instead of the boxes.
Wrapping-Up
My nephew wanted guns and maps. I gave him regions, zones, and services.
Region— where the player belongs for ping and pools.
Zone — where this match’s capacity and failure story live.
Services— the jobs: platform, matchmaking, dedicated simulation, edge, side planes.
PUBG-kind and Call of Duty–kind games share that map. They differ in match shape and fleet churn, not in inventing a different physics of distributed systems.
Mama’s rule: draw the map before you name the tool.
Mama’s second rule: a million players means many matches and an autoscaler with a warm pool — not one infinite server that shrinks every time someone is eliminated.
When someone asks how you would “design PUBG or CoD,” start with: Which region? Which zone? Which service owns this moment in the player’s journey? Then ask: What signal scales that service up — and what event lets it scale down?
One honest caveat: this design is my assumption — a teaching map from how large multiplayer backends are typically shaped, and from patterns I have used in live gaming. It may not be the exact architecture the owners of PUBG or Call of Duty run in production. Their real systems will differ in topology, naming, vendors, and secrets we do not see. Use the map to think; do not treat it as a reverse-engineered blueprint.