Multiplayer Architecture: Listen, Relay, Dedicated & Backend
Choose a multiplayer architecture by authority, transport and lifecycle: listen hosts, relays, dedicated servers, backend authority and hybrid persistence.
“P2P vs dedicated server” is useful shorthand, but it hides several independent decisions. A multiplayer architecture has at least four separate questions: who owns gameplay authority, how packets move, how players discover a session, and where durable state lives. A relay can carry packets without being authoritative. A listen server can be authoritative. A dedicated server can be reached through matchmaking without ever appearing in a public server browser.
Pick the trust model first. Then choose transport, discovery/allocation and persistence around it. Those pieces can change independently.
The four decisions hidden inside “multiplayer architecture”
| Decision | Question | Examples |
|---|---|---|
| Authority | Whose decision wins? | Listen host, dedicated process, backend service, client/relay model |
| Transport | How does realtime traffic move? | Direct UDP, relay, WebSocket, engine transport |
| Discovery / allocation | How do players learn where to connect? | Invite code, lobby, matchmaker, browser, allocator |
| Durable state | Where does state survive the session? | Player-data service, database, economy/leaderboard service |
Pattern 1: player-hosted listen server
One player's game process is both a client and the server. That host can be the authoritative simulation even though it runs on a player's machine. Other clients can connect directly or through a relay.
Unity's current Relay model is a clean example: Relay provides reachable endpoints and forwards datagrams for a listen-server pattern; the host player's process still runs the game session. Relay solves NAT/firewall/privacy problems. It does not become the gameplay authority.
What this pattern usually needs
- Session discovery: lobby, invite, join code or lightweight matchmaking.
- Transport: direct connectivity where practical, or a relay where it is not.
- Host lifecycle policy: end the match, migrate, checkpoint or elect another host when the host leaves.
- Durable backend authority where needed: progression, purchases, entitlements and ranked results should not automatically trust the hosting player's machine.
Good fit: small co-op and party games where low hosting cost matters more than a neutral host. Main trade-off: the host has a different trust and latency position from remote players.
Pattern 2: relayed/client-authoritative realtime
A relay service can route gameplay messages while remaining intentionally ignorant of their meaning. Nakama calls this relayed multiplayer: the server routes gameplay data, while clients remain responsible for what those messages mean. This can work when the threat model tolerates client authority or the game rules do not require a central simulation.
Do not confuse “traffic passes through a server” with “the server validates gameplay.” A relay can forward an impossible movement update perfectly.
What this pattern usually needs
- Authentication and session membership so only intended peers join.
- A lobby/matchmaker or invite flow if players should discover each other.
- Clear ownership rules for any contested state.
- A separate persistent backend for durable data you cannot trust to arbitrary clients.
Pattern 3: dedicated authoritative game server
A neutral server process runs the realtime simulation. Clients connect to it, send inputs/requests, and receive accepted state. The process can be manually hosted, rented, or allocated on demand; dedicated describes the process role, not how it was discovered.
What this pattern actually needs
- Admission: a way to decide which players may connect to which server.
- Discovery or allocation: a browser/registry for community-style servers, or a matchmaker/session service that returns one assigned endpoint. You do not automatically need both.
- Lifecycle: readiness, health, drain/termination and capacity handling if servers are provisioned dynamically.
- Trusted persistence boundary: send durable results/progression to a backend at meaningful boundaries rather than calling a BaaS on every simulation tick.
PlayFab documents one version of this flow: Matchmaking can allocate a Multiplayer Server for a completed match and give clients the connection information. That architecture does not require the allocated process to advertise itself in a public browser.
Pattern 4: backend-authoritative async or lightweight sessions
Some games need trusted game rules but not a continuously running physics server. A turn-based, card, board, strategy or asynchronous game can validate actions in backend/runtime code, persist the resulting state, and notify other participants. “Authoritative” still applies, the backend owns the decision, but there may be no 30/60 Hz world simulation at all.
Nakama's current authoritative multiplayer model illustrates how the same server-runtime concept can cover fast realtime, active turn-based and passive turn-based matches. A plain HTTP service can also be enough when requests are naturally discrete.
Most shipped games are hybrids, but “hybrid” should stay specific
A common production design combines one of the realtime patterns above with separate durable services: identity, player data, economy, leaderboards, live config and social features. That is a useful hybrid because session state and durable state have different lifecycles.
It does not mean every dedicated server should continuously stream ordinary simulation state into the web backend. Keep hot match state local to the realtime authority; persist checkpoints/results and other durable facts at deliberate boundaries.
Choose from the failure mode you can tolerate
| Question | Listen host | Relay/client authority | Dedicated authority | Backend authority |
|---|---|---|---|---|
| Who can manipulate the simulation? | Host process | Depends on client protocol | Trusted server process | Trusted backend code |
| Who pays realtime compute? | Mostly player host | Relay/service + clients | Operator/provider | Backend request/runtime cost |
| Host leaves? | Needs explicit policy | Depends on session model | Players stay while server lives | Usually not tied to one player's process |
| Best when | Small trusted/co-op sessions | Low-trust requirements, simple realtime exchange | Neutral realtime authority matters | Rules are discrete/async or backend-centric |
Where Crux fits
Crux's production backend covers persistent services such as authentication, player documents, economy, leaderboards, live config and server registry. Those services can sit beside a listen-hosted, relayed or dedicated networking model; they do not require Crux to own the realtime simulation.
Crux Runtime is currently a separate, capacity-gated closed alpha for approved Godot 4 Linux dedicated-server workloads in one EU region. It is not a general-purpose fleet/orchestration promise and it does not turn an arbitrary client architecture into server-authoritative netcode. If a game process runs there, that process still implements the simulation and networking model.
A practical selection sequence
- Mark valuable state. Which outcomes would matter if a player forged them?
- Assign authority. Client, host, dedicated game server or durable backend?
- Choose transport. Direct, relay, engine networking, WebSocket, etc.
- Choose discovery/allocation. Invite, lobby, browser, matchmaking, allocator, or a combination with a clear job for each.
- Choose durability boundaries. What survives the match, and which service owns that source of truth?
- Design the failure path. Host leaves, server dies, backend is slow, relay disconnects, duplicate result arrives.
If those six answers are explicit, the vendor choices become much easier and much less likely to lock unrelated layers together.