Server-Authoritative vs Client-Authoritative Game Backend Architecture

Server-authoritative vs client-authoritative is about where the final say over game state lives. In a server-authoritative game, the server runs the rules and decides what is true, so a tampered client cannot move the server's view of coins, rank, or inventory. In a client-authoritative game, the client decides and the server records what it is told. That is faster to build and fits low-stakes play, but it is open to exploitation once money or competition is involved.

Most shipping games are a mix. Server authority is standard for games with an economy or a competitive mode; client authority is common for single-player and casual titles. Retrofitting authority onto a client-authoritative game later is a rewrite, not a patch.

Server-authoritative vs client-authoritative at a glance

Category	Server-authoritative	Client-authoritative
State authority	Server is the source of truth; validates all state changes	Client reports state; server may or may not validate
Cheat prevention	Architectural: faked client state is rejected outright	Requires detection; client edits take effect until caught
Latency handling	Needs prediction and reconciliation to feel responsive	Naturally responsive; the client acts immediately
Development cost	Higher: you build prediction, sync, and reconciliation	Lower: simpler client-server flow
Consistency across clients	Guaranteed by a single source of truth	Can drift between clients
Use cases	Economies, competitive modes, ranked play, trading	Single-player, casual, prototypes, cosmetic-only state
Examples	Metaplay, Nakama (authoritative matches), Beamable microservices	PlayFab (default client SDKs), Nakama (relayed matches)

What do server-authoritative and client-authoritative mean?

Both terms describe where authority over game state resides: which side of the connection gets to decide what actually happened.

In a server-authoritative architecture, the server runs the game logic and owns the result. The player taps "buy sword," the client sends that intent to the server, and the server checks its own copy of the state (enough gold? item in stock?), applies the change, and tells the client the new state.

The client's job is to show what the server decided. If a memory editor sets the local gold to a million, the server never sees that number. It only sees a request, which it validates against the gold it already knows the player has.

Client-authoritative reverses the relationship. The client runs the logic and reports the outcome, and the server stores what it is told without recomputing it. If the client says the player now has 10,000 coins and owns the sword, the server writes down 10,000 coins and the sword.

This is simpler to build, since there is no second copy of the rules to keep in sync, and it fits a single-player puzzle game where no one but the player is affected. It is also why client-authoritative economies are exploitable once a game becomes popular.

Almost every shipping live game is a hybrid. Systems where cheating costs money or breaks fairness are made server-authoritative: currency, inventory, ranked matches, progression. Low-stakes systems are left on the client, where the security cost is not justified for a cosmetic toggle, a tutorial flag, or offline practice. The decision is less about choosing one model than about where to draw the line, and the line tends to move toward the server as a game succeeds and the incentive to cheat grows.

How does each architecture handle a transaction?

Tracing a single "buy sword" through both models shows where the two architectures diverge.

Step	Server-authoritative	Client-authoritative
1	Player taps "buy sword"	Player taps "buy sword"
2	Client sends the intent (and may show a predicted result)	Client deducts gold and adds the sword locally
3	Server validates: enough gold? item available?	Client sends the new state: "gold 450, has sword"
4	Server applies the change and persists it	Server records the reported state
5	Server returns the authoritative result; client resyncs if it diverged	(No validation step)

In the server-authoritative flow, the server is the only thing that can mint an item or move currency, so a modified client cannot grant itself anything the server would not have granted anyway. In the client-authoritative flow, step 4 trusts step 2, and step 2 runs on a machine the player controls.

Server-authoritative vs client-authoritative: trade-offs

There are trade-offs in both directions.

Server authority provides several properties. Cheating that fakes client state becomes structurally impossible rather than something detected after launch, because the server recomputes the result and rejects anything that does not add up. State stays consistent because there is one source of truth, so two clients cannot disagree about who won. When a dispute lands (a chargeback, a "my items vanished" ticket, a contested ranked result), the server's log is authoritative, so there is a record to reason from.

Server authority has two limits. It stops faked state, but does nothing about bots, input automation, or collusion, which still need their own detection. And it does not catch cheating in systems left client-authoritative.

The cost of server authority is latency and engineering. Every authoritative action involves a round trip, typically 50–200ms, so a naive implementation adds perceptible delay, and the techniques that hide that latency (prediction, reconciliation, interpolation) have to be implemented by the team. Server-side logic also costs more compute per player than simply storing whatever the client uploads.

Client authority has the opposite profile. It is immediate, cheaper to run, and faster to prototype, with the cost being exploitability and the absence of an authoritative record.

The two directions are not symmetric in cost. Going from client-authoritative to server-authoritative means moving game logic to the server, routing client calls through validation, building synchronization, and often migrating live player data. That is a project, not a refactor. Going the other way is far simpler. The early lower cost of client authority is offset later by the work required to add server authority during live operation.

How do Metaplay, PlayFab, Nakama, and Beamable implement authority?

These four platforms sit at different points on the spectrum. The summary table lists the defaults; the notes after it cover the implementation details for each.

Platform	Default architecture	Server-authoritative support	How you get it
Metaplay	Server-authoritative	Built-in	Shared deterministic C# logic, server holds authority
PlayFab	Client SDKs by default	Available (opt-in)	CloudScript or Azure Functions; server APIs gated by secret keys
Nakama	Depends on the feature	Available for multiplayer	Authoritative match handlers
Beamable	Client API calls by default	Available	C# microservices you write the validation in

Metaplay: shared deterministic logic

Metaplay is server-authoritative by default, and it gets there through shared logic: you write your game rules once in C#, and the same code compiles into both the Unity client and the .NET server. When a player acts, the action runs locally first so the UI responds immediately, then the server replays the identical deterministic code, validates the result with a checksum, and persists it.

If the client and server ever diverge, the server takes precedence and the client resyncs. As the Metaplay docs put it, "the server-side copy of the PlayerModel is always the authoritative one, thus even if a hacked client modifies its local state in memory, the cheats never propagate to the server."

This approach depends on determinism, which is also its cost. For the server to recompute a client's result and get the same answer, the shared code cannot drift between the two machines, so Metaplay requires fixed-point math instead of floating-point, deterministic (ordered) collections instead of hash-ordered ones, seeded random number generation, and Metaplay's own time classes instead of system clocks.

That is a discipline a team has to learn. In exchange, an entire layer of client networking code is not needed (the request queue, the retry loop, the wait-for-response plumbing), and faking client state cannot move the server's view of the game. (For the full mechanism, see the game logic execution model.)

One 2026 note, because it follows from the architecture rather than being a separate feature: because Metaplay ships as source you own, AI coding agents can work against the real authoritative server logic. The Metaplay Agent (public preview) installs SDK skills, and the Docs and Portal MCP servers expose the codebase to tools like Claude Code, so an agent reads the same validated rules the server enforces instead of guessing at a closed API.

PlayFab: client SDKs by default, server authority you opt into

PlayFab's client SDKs let the client read and write player data, inventory, and currency directly, so the out-of-the-box path is client-driven. PlayFab is explicit about the boundary: client API calls are, in its own words, "safe to call from any process or context," while server API calls "should only be made from a dedicated server process you control, or a carefully secured CloudScript call." That guidance lives in PlayFab's player data tutorial, not the Azure Functions reference, which is where a lot of comparisons cite it from.

To make a system server-authoritative on PlayFab you move the logic server-side and lock the client out of writing directly to it.

Option	Language	Use case
CloudScript	JavaScript	Lightweight server logic
CloudScript via Azure Functions	C#, JavaScript, others	Complex validation, external integrations
Server APIs + API access policies	N/A	Restrict which calls a client can make at all

Some write-ups describe PlayFab as "client-authoritative with no source," which does not match its capabilities. Its client SDKs are open source on GitHub and server authority is available, opted into through CloudScript backed by Azure Functions, secret-key-gated server APIs, and access policies. What is closed is the server runtime and Game Manager.

Clients talk to a closed managed backend, and server-side enforcement is something you add, not the default. Azure Functions also bills against a separate Azure subscription. We go deeper on this in Metaplay vs PlayFab.

Nakama: relayed by default, authoritative when you write the handlers

Among these platforms, Nakama's authority depends on which feature you use. For multiplayer it supports two modes.

Mode	State authority	Server logic	Use case
Relayed	Clients	None (pass-through)	Peer-to-peer style, low player counts
Authoritative	Server	Match handlers required	Competitive, higher player counts

For authoritative multiplayer, the Nakama docs state: "All exchanges of gameplay data are validated and broadcast by the server." You implement match handlers (init, join attempt, join, leave, the core loop tick, terminate, and signal) in TypeScript, Go, or Lua, and that handler code is where the authority lives.

Outside of matches, Nakama's storage and leaderboard APIs are usually called straight from clients, so a server-authoritative economy or progression system is custom server logic you write, not a default you inherit. Metaplay vs Nakama covers how that applies to a live-service economy.

Beamable: server-authoritative microservices, with validation you write

Beamable's SDK exposes client-side API calls by default; for server-authoritative logic you write Beamable microservices: C# projects that deploy as Docker containers onto Beamable's infrastructure and require .NET 8 for local development. These microservices are server-authoritative in the sense that the code runs on the server, not the client, and as the Beamable docs say, "when you need to write server authoritative code, Beamable Microservices are a good choice."

One distinction separates this from Metaplay's model. Beamable auto-generates a client SDK from your microservices: edit a Microservice class and the framework regenerates a matching client class for Unity and Unreal. The generated client is a typed API wrapper, not your game rules executing locally, and the validation that rejects a cheating client is logic you write inside the microservice, not something the framework recomputes for you.

Metaplay's shared logic runs the same deterministic game code on both sides, and the server recomputes the result rather than calling an API you defined. Both are server-authoritative; they place the authority in different parts of the system. Metaplay vs Beamable works through the trade-off in full.

When is server-authoritative worth it, and when is client-authoritative fine?

A system is made server-authoritative when getting it wrong costs real money or breaks fairness. Anything tied to real-world currency (purchased gems, the inventory they buy, player-to-player trades) is made server-authoritative, because a client-authoritative economy is open to duplication exploits. Competitive and ranked play are placed on the server too: if scores or match results are decided client-side, the leaderboard reflects which clients were modified rather than how players performed. Long-term progression is in the same category: it represents the time players invested, and protecting that investment is part of protecting retention.

Client authority applies when the stakes are low. A single-player offline game affects no one else, so server validation adds overhead with no security benefit. Prototypes and game jams optimize for speed rather than security. Casual games with no in-app purchases and no competition have little to exploit. And cosmetic-only or local-practice state (a chosen UI theme, a tutorial flag, an offline sandbox) can live on the client because cheating it gives no one an advantage.

The distinction is the system, not the title: an economy left client-authoritative is exploitable once a game becomes popular enough to be worth cheating, regardless of the rest of the architecture.

How do you keep a server-authoritative game responsive?

The round trip to the server is the cost of authority, and several established techniques hide it. Each is work the team implements.

Technique	What it does	Complexity
Client-side prediction	Client runs the logic locally for instant feedback, before the server confirms	Medium
Server reconciliation	Client re-applies the server's authoritative result, correcting any local divergence	Medium
Lag compensation	Server rewinds its world to the time the player acted (the shooter's view) before judging a hit	High
Optimistic UI	Show the expected result immediately, roll back if the server disagrees	Low
Input buffering	Queue inputs during the round trip so nothing is dropped	Medium
Interpolation	Smooth visual transitions between received states	Medium

Prediction and reconciliation are the pair most relevant to the economy and progression games Metaplay targets: the client predicts so the UI is instant, and reconciles so it converges on the server's state. Lag compensation is the technique competitive shooters use so that what appeared on screen is what the server judges: the server rewinds to the moment the player pulled the trigger rather than penalizing them for their ping.

Metaplay's shared logic model provides prediction and reconciliation as a property of the architecture: the client runs the identical code to the server, so for any valid action the prediction already matches the result the server will return, and reconciliation only does visible work on the rare divergence.

Metaplay does not provide real-time physics netcode (there is no built-in authoritative hit detection for an FPS), so twitch shooters needing frame-accurate lag compensation require a separate netcode layer. The shared-logic path covers the async and turn-based multiplayer most live-service games ship.

How should you decide for a new game?

The architecture follows from what the game contains.

If your game has...	Common approach
Real-money transactions	Server-authoritative for the economy
Competitive or ranked multiplayer	Server-authoritative for match and score logic
Leaderboards that grant rewards	Server-authoritative for score submission
Single-player only, no purchases	Client-authoritative is fine
A throwaway prototype	Client-authoritative for speed, but plan the migration if it ships
A Unity + C# codebase	Metaplay (shared logic) or Beamable (microservices)
Native Unreal as the client	Beamable (native SDK) over Metaplay (Unity client SDK only)
Self-hosted infrastructure	Nakama (Apache 2.0) or Metaplay (Private Cloud self-host)
A fully managed service you never operate	PlayFab or Beamable

For the cost side of this decision, the pricing page has worked DAU examples, and a demo covers where Metaplay fits a specific game and where it does not.

FAQ

Is server-authoritative always better?

Not in all cases. It is standard for games with an economy, trading, or competitive play, because faked client state cannot move the server's truth. It also costs latency-hiding work and more compute per player, and for a single-player or casual game with nothing worth exploiting that cost adds no protection. The architecture is matched to the stakes, system by system.

Which game backends are server-authoritative?

Metaplay is server-authoritative by default through shared deterministic C# logic. Nakama is server-authoritative for matches when you implement authoritative match handlers. Beamable gives you server-authoritative C# microservices, with the validation logic written by you. PlayFab defaults to client SDKs and offers server authority as an opt-in. Engine-only hosts like AWS GameLift run whatever authoritative server you build yourself.

Is PlayFab server-authoritative?

Not by default. PlayFab's client SDKs can write player data, inventory, and currency directly, so out of the box it is client-driven. Server authority is available (you add it through CloudScript or Azure Functions, secret-key-gated server APIs, and API access policies that restrict what clients may call), but it is something you opt into deliberately rather than the default behavior.

Is Nakama server-authoritative?

It depends on the feature. Nakama supports relayed matches (clients hold authority, the server only forwards messages) and authoritative matches (the server validates and broadcasts all gameplay via match handlers you write in TypeScript, Go, or Lua). Its storage and leaderboard APIs are typically called client-side, so a server-authoritative economy or progression system is custom server logic, not a default.

Can I add server authority to a client-authoritative game later?

Yes, though it is a project rather than a refactor. You move game logic to the server, route client calls through validation, build synchronization and reconciliation, and often migrate existing player data. The asymmetry is that deferring server authority is cheap upfront and retrofitting it later is expensive.

Does encryption or obfuscation protect a client-authoritative game?

It raises the effort to cheat; it does not prevent it. Encrypted client data has to be decrypted locally to be used, and obfuscated code can be reverse-engineered. Neither substitutes for the server recomputing or validating the result. They function as speed bumps rather than authority.