Multiplayer server architecture comes down to two decisions: which machine has the final say on what happened in a match, and whose hardware runs that machine. For competitive or persistent games, the answer is almost always an authoritative server on infrastructure you control. For casual co-op with friends, a host-based or relay setup can be enough, and far cheaper. This guide shows how to choose, what each model costs you in latency, security and operations, and how to scale without over-building.
TL;DR
- Separate authority (who decides the truth) from hosting (whose hardware runs it). Mixing them up is the most common planning mistake.
- Competitive and persistent games need a dedicated, authoritative server. Peer-to-peer suits small, trusted, casual groups.
- Use UDP for fast, loss-tolerant traffic such as positions, and TCP or WebSockets for chat, inventory and lobbies.
- Treat game servers as disposable containers behind a fleet manager, and keep matchmaking, analytics and logging out of the game server process.
- Start lean, with a relay or managed backend, and move to a full fleet when player numbers and competitive stakes justify the cost.
Table of Contents
- Authority and hosting are two different questions
- The four common models
- How to choose: the stakes decide
- Protocols: UDP, TCP and when to mix them
- Keep the game server small
- Scaling: fleets, regions and failure
- Latency and regions: placing servers near players
- Security: the part that gets skipped
- Our perspective
- Where Proud Lion Studios fits
- A staged path from prototype to live service
- Mistakes we see most often
- FAQ
- Sources
Authority and hosting are two different questions
Every multiplayer design answers two questions: which machine has the final say, and whose hardware runs it. Teams often use "dedicated" and "authoritative" as synonyms, and they are not.
- Authoritative means one process holds the final, unchangeable game state. Clients send intentions ("move forward", "fire"), and the server decides the outcome.
- Dedicated means that authoritative build runs on infrastructure no player controls: your cloud account, a bare-metal fleet, or a managed hosting service.
That gives you a useful grid. A host-based game is authoritative, but the authority is a player's machine. A dedicated server is authoritative and neutral. Pure peer-to-peer has no single authority at all. Once you see the grid, the debate over "dedicated server vs P2P" stops being a slogan fight and becomes a question about how much trust your game can tolerate.
The four common models
Pure peer-to-peer
Every player connects to every other player and each client simulates the game. There are no server bills, which is why indie teams and prototypes reach for it. The weakness is that nobody owns a single source of truth. If two clients disagree about whether a shot landed, there is no referee. Peer-to-peer is generally limited to casual co-op, turn-based games or small trusted groups, and it struggles as player counts and update rates rise.
It also leaks addresses. Connecting players directly to each other, or to a client-hosted server, exposes their IP addresses to DDoS attacks, a risk that matters the moment your game has rivalry, streamers or money on the line.
Listen server (player-hosted)
One player runs the game and acts as the server for the others. Unity's documentation describes this as a popular choice for single-player games that want to let a friend join an existing world. It gives you a clear authority, which beats pure P2P, but the host has a latency advantage, can cheat, and ends the session when they quit or lose connection. Fine for cooperative play, weak for ranked competition.
Relay server
A relay sits in the middle and forwards packets between clients. Clients stay in charge of the simulation, but every player reaches one stable address. A relay hides the IP addresses of both game servers and clients and is cheaper than a fully managed dedicated fleet. AWS describes its Realtime servers as stateless relays that pass messages and game data between connected clients. A relay solves connectivity and privacy. It does not solve cheating, because the clients still decide the outcome.
Dedicated authoritative server
The server runs the simulation. The client-server model keeps the game state on the server alone: clients send their actions, and the server updates the state and sends it back. This is the industry standard for competitive and persistent games, because a validating server can reject impossible movement, forged damage and edited memory. The price is real: hosting, orchestration, monitoring and an engineering team that can operate it.
| Model | Who decides truth | Cheat resistance | Running cost | Best for |
|---|---|---|---|---|
| Pure peer-to-peer | Nobody (each client) | Low | Lowest | Prototypes, turn-based, small trusted groups |
| Listen server | One player's machine | Low to medium | Low | Co-op, friends-only sessions |
| Relay | Clients | Low, but IPs protected | Medium | Casual real-time games that need reliable connectivity |
| Dedicated authoritative | Your server | High | Highest | PvP, ranked, persistent worlds, games with real-money economies |
How to choose: the stakes decide
Experienced practitioners treat the "best" architecture as a balance, not a rule. Server-authoritative setups are the gold standard for PvP fairness, but they are expensive and operationally complex. A pragmatic path, often recommended on the Game Development Stack Exchange, is to launch an MVP on a managed relay or a serverless session backend, then graduate to fleet-managed dedicated servers once the player base and competitive pressure justify the overhead.
Four questions settle most decisions:
- What does cheating cost you? In a casual co-op game, little. In a ranked shooter, a tournament title or a game with tradable assets, everything.
- How fast is your simulation? Hardcore PvP titles often target updates every 16 ms, or 60 per second, and that is where P2P begins to break down.
- Does the world persist? If players come back to the same state tomorrow, something must own that state permanently. That means a server.
- How many players per match, and how spread out are they? Eight friends in one city and 100 players across three continents are different engineering problems.
If you answer "high" to the first and third questions, plan for dedicated authority from day one, even if the first release is small. Retrofitting authority into a client-trusting game is one of the most expensive rewrites in game development, because every gameplay rule has to be moved and re-validated.
Protocols: UDP, TCP and when to mix them
The question "are games UDP or TCP?" has a short answer: both, for different traffic.
- UDP is the usual choice for performance-critical real-time traffic such as positions and physics, because it favors speed and tolerates packet loss instead of waiting for retransmission. A position update that arrives late is worthless, since a newer one is already on its way.
- TCP or WebSockets carry traffic where order and delivery matter more than speed: lobby communication, inventory changes, purchases and chat.
Pure UDP with no safeguards creates its own trouble in fast games. The usual fix is a thin reliability layer, whether QUIC or custom sequencing and acknowledgments, applied only to the messages that need it. A typical split looks like this:
| Traffic | Transport | Reason |
|---|---|---|
| Player position, rotation, projectiles | UDP, unreliable | Stale data is useless |
| Critical events (match start, kill, score) | UDP with reliability layer | Must arrive, but cannot block movement |
| Chat, friends, inventory, store | TCP or WebSocket | Order and guaranteed delivery |
| Matchmaking and session APIs | HTTPS | Standard, cacheable, easy to secure |
Keep the game server small
A common failure pattern is over-engineering the backend too early. Unity's multiplayer guidance opens with the advice to simplify your architecture and warns that adding metrics, logging, telemetry and monetization too early can bloat the design.
The practical rule: the game server is one lean, ephemeral process. It simulates a match, then exits. Matchmaking, analytics, player profiles, inventory and logging live in separate stateless backend services. Packing them into the game server executable creates resource contention and "zombie" instances that keep costing money after a crash.
A healthy layout has these parts:
- Game client, built in your engine of choice, talking to the services below.
- Backend APIs for accounts, inventory, progression and store, kept stateless so they can scale behind a load balancer.
- Matchmaker that groups players and requests a server.
- Fleet manager that starts, tracks and retires game server containers.
- Game servers, each hosting one match or one world shard, holding state in memory only while the match lasts.
- Persistence layer (database and cache) that stores what must survive the match.
A game server is stateful during a match, so you cannot swap it freely mid-game. You can, however, make it disposable between matches, and that is the property that lets you scale.
Scaling: fleets, regions and failure
Scalable multiplayer is built by treating game servers as ephemeral workers orchestrated by container-based fleet managers. The fleet grows when players arrive and shrinks when they leave, and one failed instance does not disturb other matches. Managed services such as PlayFab Multiplayer Servers, which dynamically scales custom game servers on Azure compute, and Amazon GameLift offer this off the shelf, including multi-region deployment, so you do not have to build your own orchestrator.
A few scaling habits save pain later:
- Scale horizontally. Add servers rather than bigger servers. Any scalable system adds capacity by adding servers, which means load balancing, and the split between matchmaking and game servers makes that possible.
- Keep matches independent. If every match is isolated, a crash affects one group of players, not the game.
- Load test early. Simulate bots at your target concurrency before launch, not after the first marketing push.
- Consider serverless for the non-real-time parts. AWS described how the shooter Crucible built its backend platform entirely on serverless technologies, which reduced operational load. That pattern fits accounts, lobbies and inventory well, though not the real-time simulation itself.
For the wider planning picture beyond games, our app scalability planning roadmap covers capacity, databases and growth stages.
Latency and regions: placing servers near players
Network latency has a physical floor set by the speed of light. Global titles therefore use regional servers, and the most robust strategy is to place servers close to players or carry traffic between regions over a cloud provider's private backbone rather than the public internet, which is prone to packet loss and instability.
For a studio selling to the Gulf and beyond, this has direct consequences. Pick regions by where your players actually are, not where your engineers sit. Players in the UAE, Saudi Arabia and India do not share a latency profile with players in Europe.
The smart way to match players to regions is to measure before you allocate. Cloud platforms use QoS beacons, and PlayFab documents using them to measure player latency to Azure regions before a server is chosen. The client pings each candidate region over UDP, reports the results, and the matchmaker starts the server where the group's combined latency is lowest. This is a modest amount of work that noticeably improves connection stability.
Also design for regional failure. Do not assume two nearby data centers give you redundancy. Keep at least one fallback region far enough away that a local incident does not take out both, and test the failover before you need it.
Security: the part that gets skipped
Authority protects the game rules. The transport layer needs its own protection.
- Validate everything server-side. Speed, cooldowns, ammo, positions and purchases should all be checked against rules the client cannot change.
- Hide your servers. A relay or gateway layer that validates and rate-limits traffic. AWS's player gateway, for example, uses a relay network to route UDP traffic and protect against DDoS attacks before packets reach game servers.
- Do not expose player IPs. Pure P2P and client-hosted servers make this impossible to avoid.
- Authenticate on the backend. Issue short-lived session tokens from your account service and have the game server verify them on connect.
If your game has an economy, add a further rule: the game server never trusts the client about value, and any asset transfer goes through a backend that can be audited. That applies doubly to games with tokenized items.
Our perspective
We build multiplayer games, blockchain products and AI systems from a fully UAE-based team, and the same pattern repeats: studios do not fail because they chose the wrong netcode library. They fail because they chose an architecture that did not match their stakes, then paid for it twice.
Our view is simple. Decide authority first, and decide it by the cost of cheating. If your game has ranked play, a shared persistent world or an in-game economy, build on an authoritative server from the first prototype, even if that prototype supports only a few players. If your game is a casual co-op title, a relay with a clean session backend is a perfectly respectable launch architecture, and you can keep the door open to a dedicated fleet later by keeping game logic out of the client where you can.
We also push clients to resist building everything at once. A lean server process, a stateless backend and one or two well-chosen regions will carry a game much further than a sprawling platform no one can operate. Tailored beats templated here, because a card game, a battle royale and a blockchain-backed collectible game have almost nothing in common at the network layer. We would rather spend your budget on the parts players feel.
— Amal
Where Proud Lion Studios fits
If you are planning a competitive or persistent title, our team can scope the server model, the backend services and the game itself together. See our AAA multiplayer games and mobile games services, or read how we approach building multiplayer games with blockchain and AI. For companion web or mobile products around your game, such as an admin panel, a store or a player portal, a custom web application with backend, database and admin panel starts from 25000 USD one-off, and an MVP on a single platform) starts from 15000 USD one-off. If your game uses on-chain assets, our smart contract suite with frontend integration starts from 20000 USD one-off. Game server work itself has no published price, because it depends on your design. Tell us what you are building and we will scope it with you.
A staged path from prototype to live service
Most teams do not need the final architecture on day one. A staged plan keeps cost in line with risk:
- Prototype. Use a listen server or managed relay. Goal: prove the game is fun with a handful of players. Keep game logic in a form that can move to a server later.
- Closed alpha. Move the simulation onto a dedicated authoritative server, even a single instance. Add basic validation and logging. Measure real latency from your testers' locations.
- Open beta. Introduce a matchmaker, a fleet manager and two regions chosen from beta data. Add DDoS protection and load tests.
- Launch. Autoscale the fleet, set alerts on match start time and server crash rate, and rehearse a regional failover.
- Live service. Split out analytics, anti-cheat and economy services as separate backend components, so the game server stays lean.
Our article on multiplayer game design tips for developers covers the design side that sits on top of this stack, and why scalable app development matters for growth explains the business case for building capacity in steps.
Mistakes we see most often
- Trusting the client "just for now." Temporary trust becomes permanent because gameplay is built on it.
- One giant server process. Matchmaking, chat, analytics and simulation in one executable make every crash expensive.
- Choosing regions by habit. Data on player locations should pick regions, not the office address.
- Skipping a relay or gateway. Exposed IPs invite DDoS attacks on both players and servers.
- Paying for scale you do not have. A fleet sized for a million players costs the same whether or not they show up. Autoscaling and a staged rollout fix that.
- Treating TCP as the safe default. Head-of-line blocking makes position updates feel laggy. Use UDP for state and reserve TCP for the data that must be ordered.
FAQ
Is a dedicated server always better than peer-to-peer?
Not always, but it is better whenever fairness, persistence or security matter. A dedicated authoritative server gives you a single source of truth that clients cannot tamper with. Peer-to-peer costs less and can suit casual co-op, turn-based games or small groups of trusted friends.
Are multiplayer games UDP or TCP?
Both. Real-time state such as positions and physics usually travels over UDP, because speed matters more than perfect delivery. Chat, inventory and lobby traffic typically uses TCP or WebSockets, where reliability and order matter more than latency.
What is the difference between a relay server and a dedicated server?
A relay forwards packets between clients but does not run the game, so clients still decide outcomes. A dedicated server runs the simulation itself and validates every action. A relay helps with connectivity and hiding IP addresses. A dedicated server is what prevents most cheating.
How do I keep multiplayer server costs under control?
Start with a relay or managed backend and add dedicated servers when your player base and competitive stakes justify them. Keep the game server process lean, run it in containers, and let a fleet manager scale it with demand. Choose regions from real player data so you do not run capacity where nobody plays.
When should I involve a development partner?
Bring one in before you commit to an engine and netcode, because authority and hosting choices are hard to reverse. A studio can scope the server model, backend and client together, so the architecture matches your game and your budget.
Sources
- Authoritative Servers, Relays & Peer-To-Peer: networking types and their benefits
- Client-Server Game Architecture
- Create a game with a listen server and host architecture, Unity
- How player gateway works, Amazon GameLift Servers
- Amazon GameLift Servers Realtime Servers Developer Guide
- Difference between P2P, relay servers and dedicated game servers, Game Development Stack Exchange
- QoS beacons to measure player latency to Azure, PlayFab
- Servers, PlayFab, Microsoft Learn
- How to Build and Design a Multiplayer Game, Unity
- Building a Scalable Multiplayer Game Architecture, Rune
- Crucible, behind the curtain, AWS for Games Blog