Which Multiplayer Architecture Fits a Live Game?

How to choose between peer-to-peer, relay, and dedicated game servers for a live game.

The right multiplayer architecture for a live game depends on four things, not on a brand. Start with your cheat risk, your session size, and your players’ networks. Then weigh how much hosting you want to run, and pick the model that matches.

Get this call right early. The netcode model shapes your latency budget, your anti-cheat, and your bill. A dedicated game server that runs your game loop carries a different cost and ops profile than peers talking directly.

This is a decision guide, not a vendor bake-off. Our walkthrough on how to make an online multiplayer game covers the full build, from engines to netcode to backend. Here we focus on the architecture choice: the three models, the four questions that pick between them, and where the persistent backend sits next to hosting and orchestration.

The three multiplayer models, in one view

Every live game runs on one of three netcode models, or a blend of them. Peer to peer connects players directly. A relay server forwards their packets through a middle box. A dedicated server runs your game logic itself. Each one trades latency, cost, and control against how well it stops cheating.

With peer to peer, one player often acts as host and holds the match state, and the others connect to that host. A relay server keeps clients in charge but gives every player one stable address to reach, which is why it survives hostile networks. A dedicated server does more than pass messages. It runs the simulation and stays the single source of truth for the match. This is a build-time decision, and it is expensive to reverse once a game ships, so match the model to the game before you write netcode.

The table is the short answer. The rest of this guide is how to pick your row.

Do I need dedicated servers or peer-to-peer?

You need dedicated game servers when cheating hurts the game or sessions grow large. Peer to peer is fine when neither is true. Teams frame this as peer to peer versus dedicated game servers, and the deciding factors are cheat sensitivity and session size.

Cheat sensitivity comes first. In a peer to peer match, one player’s device holds authority, so a modified client can rewrite the game. That is fine for a co-op puzzle and unacceptable for ranked PvP. A dedicated, server-authoritative model keeps canonical state on hardware you control, so the server checks every move and a hacked client changes nothing.

Session size is the second axis. Direct peer connections scale badly as a match grows, because every player has to talk to every other player. Past four or so players, a server in the middle is simpler and cheaper to reason about. Large lobbies and persistent worlds almost always want a server holding the match.

There is a cost side to this too. A dedicated model spends server compute on every live match and asks your team to run that fleet, so you trade money and operations for control and fairness. Peer to peer spends almost nothing on servers, because the players’ machines do the work. Relay sits in between and pays only for bandwidth through the middle box. None of that changes the anti-cheat picture, so let cheat sensitivity, not cost, make the first cut.

What is a relay server in multiplayer games?

A relay server is a machine that forwards game packets between players without running your game logic. It fixes connectivity while leaving clients in charge of the match. It sits between peer to peer and a full dedicated server. In relay server multiplayer games, the relay solves the network problem, not the trust problem.

The connectivity problem is real. Most players sit behind NAT, so two devices often cannot open a direct connection on their own. Methods like STUN and ICE try to punch a direct path first, and a relay is the reliable fallback when that fails. The TURN standard, RFC 8656, defines this kind of relay around NAT. Mozilla’s overview of WebRTC protocols walks through how STUN, TURN, and ICE fit together.

Relay shines in two places. The first is any title where clients are trusted enough that you do not need server validation, like many casual and cooperative games. The second is any audience on carrier-grade NAT, where direct connections fail often and a relay is the difference between a match that starts and one that hangs. You keep the low latency of client-driven play and drop the connection headaches.

Because a relay only forwards traffic, it adds one hop of latency and almost no server cost. It gives you no server-side validation. That is the trade. You get reach and simplicity, and you keep trusting the clients.

The four questions that pick your architecture

Run these four questions in order. Each one narrows the model, and the last one sets how much you host yourself.

1. How much does cheating hurt you? If a cheater ruins the experience or the in-game economy, go server-authoritative. A looter shooter with lootable inventory keeps that inventory and player bans on the server. Marauders is the example we use: Small Impact Games ran accounts, storage, and bans on Nakama, and used banning to combat cheating in the genre.

2. How big is a session? Two to four players tolerate peer to peer well. Larger lobbies and persistent worlds want a server in the middle so the topology stays sane and one slow host cannot drag the match down.

3. How hostile are the networks? If your audience plays on mobile or console behind strict NAT, plan for a relay path so matches still connect. A trusted-client mobile card game is a classic relay fit, since the stakes are low and the networks are unpredictable.

4. How much hosting and ops can you carry? Dedicated game server hosting means running, patching, and scaling a fleet of match instances yourself. Managed game server hosting takes that load off a small team so engineers stay on the game.

Take two games through the list. A five versus five competitive shooter answers yes to cheating, medium on session size, and mixed on networks, so it lands on a dedicated, server-authoritative model with a relay fallback for voice. A two player mobile card game answers no to cheating, small on session size, and hostile on networks, so it lands on a relay path with a light backend behind it. Same four questions, two different rows.

Most live games end up blending these. A shooter can run authoritative combat, relay voice chat, and still fall back to a relay when a direct path fails.

Where the persistent backend fits

Netcode is only half of a live game. Every model still leans on a backend for accounts, matchmaking, and saved progress. That persistent realtime multiplayer backend runs beside your hosting and orchestration, not inside your netcode.

Matchmaking is the clearest case. It has to see every online player to pair them well, so it belongs in a backend that all clients talk to, not on any one player’s device. The same is true for leaderboards, stored progress, and social graphs. That is why the backend and the netcode stay separate concerns, and why picking a netcode model does not pick your backend for you.

This is where we build. Nakama is our open-source game backend, used by more than 1 million developers.

Nakama is not tied to one model. It runs server-authoritative matches: your game loop executes on the server at a tick rate you set from 1 to 60 Hz. The server holds canonical state and validates every input. When you run authoritative matches on Nakama, that handler is your server-side simulation, sitting with the rest of the backend rather than in a separate dedicated game server fleet. It also ships a relay path for trusted-client titles, and it coordinates fleets of headless dedicated servers through its FleetManager interface. Underneath sits the persistent backend every live game needs. It covers auth, matchmaking, and storage. Friends, leaderboards, and chat live there too. Because Nakama is open-source, you own the code and your data. You can self-host it or hand operations to a managed host later, without a rewrite.

The scale is proven. Nakama runs on Apache 2.0 and has held up in performance tests at 2M+ peak CCU. Small Impact Games moved Marauders to Nakama before launch. It ran 330,000+ player accounts and 25M+ storage objects in a single region, without the backend buckling. Hitting numbers like those is a design problem, and our guide to game backend scalability best practices lays out the patterns.

For publishers and larger studio orgs, the operational load is the real question, not the code. Heroic Cloud is the managed path there. It runs dedicated Nakama clusters that scale within seconds with zero downtime, multi-region on AWS and GCP. It adds SOC 2 Type II compliance and a private cloud option for teams that need one. That is the enterprise game backend route, and it adds production ops without rewriting your stack.

Match the model to your cheat risk, session size, and network reality. Then size the ops you can carry, and put a persistent backend behind it. If you want that backend open-source and ready to scale, start with Nakama.