A player posts a leaderboard time that's physically impossible. Another one ends a match with an inventory full of an item that only drops from a boss they never fought. Somewhere in your stack, the game was asked a question, "did this really happen?", and it answered "sure, I'll take your word for it."
That's the whole topic, really. Not "which architecture is better." The question underneath every multiplayer design decision is narrower and more useful: when a client claims something happened, who does the game believe? Answer that per feature and the architecture mostly designs itself. Get it wrong on the features that matter and no amount of anti-cheat bolted on later fully saves you.
So let's define the two ends of that, walk the tradeoffs that actually decide it, and look at how the pieces fit in a real match.
Strip away the jargon and there's a single question: where does the authoritative copy of the game state live, and whose word is final when two copies disagree.
In a client-authoritative model, the player's machine computes what happened and reports the result. "I moved here." "I hit that player." "I picked up 400 gold." The server, or the other players' machines, take that report and apply it. The client is trusted to run the rules honestly. This is fast, it's cheap, and it's simple to build, because the machine that has all the input is also the one making the decisions.
In a server-authoritative model, the client doesn't report results. It sends intent: the buttons the player pressed, the direction they aimed, the request to fire. The server runs the actual game simulation, decides what those inputs produce, and sends the resulting state back to everyone. The client, in Gabriel Gambetta's phrase from his client-server architecture writeup, becomes a "privileged spectator", it renders the world and captures input, but it doesn't get to decide what's real. The rule of thumb an engineer will repeat back to you: if a player can gain an advantage by lying, that thing runs on the server.
Most shipped games aren't purely one or the other. They sit on a spectrum, and where a given game lands is usually decided by how it handles hosting:
Pure client authority: offline, LAN, or fully trusting clients. Fine when there's no competitive stakes and nobody to cheat.
Peer-to-peer / listen server: one player's machine acts as host. That host is semi-authoritative, better than everyone trusting everyone, but the host is still a player's box, with all that implies.
Relay: a middle service forwards packets between peers so they can connect through firewalls, but the game state still lives on the peers. It solves connectivity, not trust.
Dedicated authoritative server: a neutral machine you control runs the match. Nobody playing owns the truth.
That spectrum exists because moving authority to the server buys you something valuable and charges you for it in three currencies: cheating resistance, latency, and cost. Every real decision is about which of those you're most willing to spend.
Here's the uncomfortable truth that drives the whole server-authoritative argument:
Anything running on the player's machine is hackable. Not "hackable if you're careless", hackable, full stop. As the author of the Development and Deployment of Multiplayer Games series puts it, whatever you hand to the player should be considered compromised; the best you can do is raise the cost of hacking, not eliminate it. You cannot win a fight on the attacker's home turf, and the player's PC is their home turf.
This is why client authority leaks. If the client decides how much gold you have, then a memory editor like Cheat Engine can change that number, and the game believes it, because the client was the source of truth. If the client decides whether a shot hit, a modified client reports every shot as a hit. The values a cheater can touch are exactly the values the client was trusted to own.
Move authority to the server and that entire attack surface collapses. Cheat Engine can still edit the number your client displays, but the server holds the real one, and it ignores whatever the client claims. This is the specific, mechanical reason server authority works: the cheat never gets to assert state in the first place. It shuts down whole classes of exploit at once, speed hacks, teleporting, item duplication, currency generation, instant-kill hit injection, because all of those depend on the client's word being accepted, and the server stopped asking.
Peer-to-peer sits in an awkward middle. When one player's machine is the host, cheating patterns cluster around that asymmetry: lag switching (choking your own connection to freeze others while you keep moving), data tampering, ghosting or wallhacks that reveal information the player shouldn't have, and look-ahead cheats that read intercepted packets to react to what opponents are about to do. Duplication via packet replay, sending the same "I bought this" transaction twice to clone the item, has stubbornly survived into recent mobile titles for the same reason. There's no neutral referee. The Dark Souls III community spent years on exactly this complaint: peer-hosted invasions meant a modded client could sit in your game with no authority above it to say no.
Now the concession, because this is where a lot of writing on the topic overpromises. Server authority is not the same thing as anti-cheat, and it does not catch everything. It's a different layer from kernel-level anti-cheat like Easy Anti-Cheat or BattlEye. Those run on the player's machine and watch for tampering, injected code, or known cheat signatures. Server authority does the opposite: it assumes the machine is lying and refuses to trust its reports. The two solve different problems. A server that owns the game state still can't see a wallhack that only changes what the player's GPU renders, and it can't see an aimbot running on a second machine reading the screen with a capture card, because neither of those sends a dishonest packet. They abuse information the player legitimately received.
So the real defense is layered, and the layers catch different things.
Server authority is the foundation because it's the one layer that removes exploits by construction rather than by detection, and it's an architecture decision you make once, not an arms race you re-fight every patch. Then server-side telemetry catches the statistical cheats (accuracy that's too good, reaction times no human hits), and kernel anti-cheat handles the render-and-read cheats that never touch the wire. Most competitive games run all three. If you only have budget and attention for one, the server owning state is the one that pays for itself, because it kills the exploits that destroy economies and ladders outright.
We go deeper on that specific layer in a separate piece on server-authoritative logic for cheat prevention. For here, the point is just that authority is where the durable protection starts.
If server authority is so much safer, why not run every game that way, all the time, for everything? Because a naive server-authoritative setup feels terrible to play.
Walk through what happens with a "dumb" client that only sends inputs and waits. The player presses right. That keypress travels to the server. The server processes it, advances the simulation, and sends the new state back. Only then does the character move on screen. On a LAN that round trip is invisible. On the actual internet, where latency runs from tens to hundreds of milliseconds, the character starts moving a noticeable beat after the key goes down. Gambetta is blunt about the result: at internet latencies, a naive implementation feels unresponsive at best and unplayable at worst. Nobody ships a shooter where movement lags a fifth of a second behind the controller.
The fix is the set of techniques that make server authority survivable, and it's most of the actual netcode engineering in a real-time game:
Client-side prediction. The client doesn't wait. It runs the same simulation locally and immediately shows the result of your input, betting that the server will agree.
Server reconciliation. The server is still the authority. When its answer comes back and it differs from what the client predicted (because of lag, a conflicting action, or a cheat attempt), the client snaps to the server's version and replays the inputs that happened since. Get this wrong and players see rubber-banding, that yank backward when the correction lands.
Entity interpolation. For other players you don't control, the client has no inputs to predict with, so it smooths their movement between the server snapshots it does receive.
Lag compensation. When you fire, the server rewinds the world to what you actually saw on your screen a few milliseconds ago, then checks the hit against those past positions. This is the "favor the shooter" model, it's why you sometimes die a half-second after ducking behind cover on the killer's screen.
Through all of it, one rule holds: the server validates every input before it acts on it. A modified client can send "I moved 500 meters this tick" or "I fired with an empty magazine," and the server's job is to run its own simulation and reject anything impossible. Prediction makes the game feel local; validation keeps it honest.
The knob that ties this together is tick rate, how often per second the server recomputes authoritative truth. Higher tick rate means the server's picture is fresher and hit validation is more precise, at the cost of more CPU per match and more bandwidth per player. Valorant is the well-known example of a studio spending hard on this: Riot runs 128-tick servers and built its own network backbone, and in their own testing that combination shaved roughly 40 milliseconds, about 28 percent, off "peeker's advantage," the edge a moving attacker has over a defender holding an angle. That's the return on investment for authority done at high fidelity, and it is not cheap to reach.
Here's the honest part: this is where the real difficulty lives. Deterministic simulation shared between client and server, reconciliation that doesn't feel like a yank, tuning the prediction window so corrections are rare, lag compensation that's fair to both the shooter and the target, none of it is free, and all of it is work a client-authoritative game simply doesn't have to do. Server authority doesn't remove complexity. It moves the complexity from "cleaning up after cheaters" to "making a correct simulation feel instant." Teams choose that trade because the second problem is solvable and the first one isn't.
The last currency is the one studios underestimate most, because it doesn't show up until you're closer to launch.
Client-hosted and peer-to-peer models are close to free on the infrastructure line. There's no fleet to run, no per-match server cost, no DevOps rotation. The host is a player's machine, and players bring their own hardware. For a co-op game, a party-based experience, or anything where the stakes of a cheater are "one lobby has a bad time," that's a completely reasonable place to stop. Plenty of good games are peer-hosted on purpose, the economics are just better and the player never notices.
Dedicated authoritative servers cost real money and, more importantly, real engineering. You're now running a game server per match, and to keep players from waiting on a cold start you keep a buffer of servers pre-warmed and idle. You scale the fleet up when concurrency spikes and down when it drops, or you either leave players queuing or burn budget on empty VMs. You run those fleets in multiple regions so a player in Frankfurt isn't routed to Virginia. And underneath the hosting, the authoritative backend itself is a serious build: owning state, making mutations transactional so a dropped connection mid-purchase doesn't dupe or vanish an item, validating actions with lag compensation, and piping events somewhere you can actually analyze them. That backend is the piece teams chronically underestimate, and it's usually the thing half-built and on fire during launch week.
This is the point where "build versus buy" stops being abstract. The authoritative-server layer is commodity infrastructure in the sense that every real-time game needs roughly the same thing, and it's specialized in the sense that getting it wrong is expensive and public. If you want a fuller decision framework for that, we wrote one on how to choose a game backend. The short version: the cost of server authority is genuine, and pretending otherwise is how teams get surprised at the worst possible time.
Abstract models are easy to nod along to and hard to act on, so here's the whole thing end to end, one competitive match, watching where authority sits at each step.
Matchmaking forms the lobby and picks ten players. First real decision: who hosts? If this is a peer or listen-server game, one player's machine is elected, and that machine is now semi-authoritative, good enough for casual play, a soft spot for competitive. If it's a dedicated-server game, a neutral server is claimed for this match and nobody playing owns the state.
The match starts. Each client captures inputs, moves, aims, fires, and does two things with them: it predicts the result locally so the screen responds instantly, and it sends the raw intent to the authority. The authoritative server runs its simulation tick, decides what actually happened, and validates as it goes: a claimed position that's too far for one tick gets rejected, a fire event with no ammo in the server's copy of the magazine gets dropped. Then it broadcasts authoritative snapshots to every client, which reconcile their predictions against them and interpolate the other players' movement between updates. When someone fires, the server rewinds to that shooter's view for hit detection. Every few dozen milliseconds, that loop runs again.
The match ends. Now authority matters in a different way. The final result, who won, what each player earned, what dropped, gets written from the server to the backend: stats, progression, economy, battle pass. Because the server owned the match, that write is trustworthy; the leaderboard entry and the item grant reflect what actually happened, not what a client asserted. Then the dedicated server, having hosted its one session, is torn down and replaced, ready for the next match.
Notice what stayed client-side the whole time and was fine there: the UI, cosmetic effects, anything read-only. You don't need the server to authorize which weapon skin renders. Authority is a cost you spend where lying pays, and cosmetics are a place lying doesn't.
It helps to ground this in tools developers actually reach for, treated accurately, because most real stacks mix them.
Epic Online Services is the widely used example of the peer-and-client-hosted-leaning end, and it's genuinely strong at what it does. It's free, it's engine-agnostic, and it gives you identity, a massive cross-platform friends graph, voice, lobbies, sessions, and peer-to-peer connectivity with NAT traversal handled for you. Its P2P interface establishes the connections between players' game clients, and, importantly, it hands you the decision of what data flows between them and how much any client is trusted. That's the nuance worth stating precisely: EOS doesn't force client authority, it's connectivity and services plumbing, and it leans peer-hosted by default. Epic's own documentation and integration partners are clear that the P2P relay is not a dedicated authoritative server; for a game that needs authoritative hosting, you bring and run that server yourself. EOS even has a "trusted server" client policy for exactly that setup, but the trusted server is yours to host. And its Player Data and Title Storage are encrypted key-value stores, useful for saves and config, not an authoritative game-state database. For a P2P co-op game that mainly needs cross-play, friends, and voice, EOS on its own can carry the whole thing.
The server-authoritative end is a dedicated game server that runs the match, plus the orchestration to keep a fleet of them alive. As a concrete example of how that layer is structured, AccelByte Multiplayer Servers runs your own Unreal, Unity, or custom server binary as the authority, you keep your game and session logic, and the platform runs the infrastructure underneath it: provisioning virtual machines, managing fleet lifecycle across regions, pre-warming buffers so players don't wait, scaling with demand, and recovering from crashes, across multiple clouds and bare metal. The match flow is the claim-and-connect pattern from the walkthrough above: when a match is ready, the session service claims a server, gets back an IP and port, and hands those to the matched players, who connect directly to the authoritative server.
The reason these two get presented as rivals is mostly a category error, and it's worth clearing up because it changes how you build. They operate at different layers, and in practice they're often paired. AccelByte's own documentation describes running its dedicated servers alongside a game that uses EOS or Steam, with a self-claim flow for exactly that case. The real-world competitive stack frequently looks like EOS for identity, social, voice, and connectivity, plus a dedicated authoritative host for the match itself and a backend for the economy and progression the match writes into. If you want the deeper networking comparison specifically, we broke down peer-to-peer versus relay versus dedicated servers separately. The takeaway here is that "server-authoritative versus client-authoritative" is a spectrum you position each part of your game on, not a single vendor you pick.
The architecture question sounds like it's about topology, clients and servers and who talks to whom. It isn't. It's a trust question asked one feature at a time. For each thing your game tracks, ask what happens if a player lies about it. If the honest answer is "nothing important," a cosmetic, a UI state, a single-player save, let the client win and keep your costs and your latency low. If the answer is "the match result, the economy, or the ladder is now a lie," the server has to own that piece, and prediction, tick rate, and a server budget are simply the price of buying responsiveness and trust back at the same time.
Client-authoritative is cheaper and simpler right up until someone has a reason to cheat. Server-authoritative is more expensive and harder right up until you need anyone to trust the result. Most games are both, on purpose, and knowing which parts are which is the actual skill.
Decide where your game's truth lives before a player decides it for you.