Where does the Unity backend begin?

Separate three responsibilities.

A player’s position during a match, an unlocked item and an authenticated account belong to different lifecycles. Treating them all as “backend data” hides the decisions that make a networked game understandable.

Match state

Positions, inputs and short-lived gameplay state belong to the networking model. Their update rate follows the game, rather than the availability of a database API.

Persistent state

Progress, inventory and preferences must survive the current session. Decide which service stores each field and which system is permitted to change it.

Identity

Authentication establishes who is making a request. It does not establish that a claimed reward or match result is valid.

Send an intention, not a trusted result.

Consider a reward claim. “Give me 500 coins” asks the client to define the result. “Claim reward for match X” gives the authoritative service something to validate against its own evidence. The service still needs to verify the caller, eligibility and whether that reward has already been granted.

This is an illustrative design, not code taken from a client project. The correct validation depends on the game’s authority model and the evidence it can retain.

Design the retry before the happy path.

A request can succeed while its response is lost. Retrying a non-idempotent operation can then grant the same reward twice. Give the operation a stable identity, make duplicate detection and state mutation atomic, and return the recorded result for a retry. Disabling a button helps the interface; it does not provide this guarantee.

Also decide what the player sees during a timeout. Keep an unconfirmed reward distinct from a confirmed balance, and reconcile against authoritative state when the connection returns.

Make the boundary inspectable.

For one important action, write down the caller, authority, stored state, failure cases and recovery behaviour. Then test duplicate requests, stale sessions and a disconnect immediately after acceptance. That small table often exposes more than another layer of service wrappers.

In GPixel, my documented work includes PlayFab player data and authentication, with Azure Functions supporting backend services. The principles above are general guidance, not a claim about that project’s reward implementation.

References and next steps.

PlayFab distinguishes client-writable, read-only and internal player data. Server-only calls belong in a trusted server environment. See Microsoft’s player data documentation and the server/client API quickstart.

For the visual side of networking, try the snapshot interpolation lab. For project support, explore Unity multiplayer development.