Photon Realtime Room-per-Match Design with Master Client Authority

The problem with a pure relay

You need a small multiplayer game backend without running game servers, but Photon Realtime's relay model means any client can raise events. The useful takeaway is that the smallest viable design is one room per match with a Master Client acting as a lightweight arbiter, but Photon is not authoritative.

Requirements for a small Photon Realtime backend

A minimal backend needs match discovery, state sync for a small player count, and tolerance for disconnects. Room is the core abstraction: clients join a named room or are placed by lobby matchmaking, then communicate inside that room.

RaiseEvent is the messaging primitive. It is not a RPC call; it is an untyped event relayed to subscribers. Event codes are integers you define. Payload size and frequency are constrained by plan limits.

Cost is metered by concurrent users (CCU) and message throughput. Tick rate, event granularity, and room size directly drive both.

Smallest suitable design: one room per match

One room per match or session is the minimal topology. Use a room code for direct join or lobby properties for discovery. Keep the room closed once full to avoid mid-match joins unless spectating is intended.

State sync without a custom snapshot can use event caching. RaiseEvent with a caching option lets late joiners receive the last cached state events for that event code. This avoids building a separate snapshot protocol, but stale cache entries must be explicitly cleared to avoid resurrecting old state.

Interest groups and event filtering limit which clients receive which events. Using them early keeps bandwidth and message counts within plan limits as room populations grow. Map the room into groups for local relevance and broadcast only global events to all.

Check the current Photon Realtime/PUN SDK release notes for caching options, interest group limits, and any API changes since your SDK version.

Trust and data boundaries

Photon is a relay, not an authoritative simulation. By default any client can raise any event. The trust boundary sits at the client.

The smallest authority model available is the Master Client pattern. Photon designates one client per room as master and migrates it automatically on disconnect. Use it to arbitrate turns, spawns, or scoring, but treat it as a convenience, not a security boundary.

Design the protocol so the Master Client validates and rebroadcasts. Non-master clients should never apply their own moves locally without confirmation. For anything competitive, validate on a Master Client or move critical logic to server authority instead of raw relay.

Data classification: treat all client-sent data as untrusted. Never trust client timestamps, scores, or inventory deltas without validation. Keep sensitive matchmaking parameters server-side in room properties set by the host.

Operational checks and cost control

Confirm your plan's CCU and messages-per-second limits in the Photon dashboard before load testing. The design decision of tick rate, event granularity, and room size drives cost.

Practical checks:

• Measure actual message rate per room at target population. Coarser events and interest groups reduce both bandwidth and message count.
• Simulate Master Client disconnect during active play to confirm state handoff and that no events are lost or double-applied.
• Test a late-join flow to confirm cached events reconstruct room state correctly and that cleared cache entries are not replayed.

Event cache hygiene: cached events persist for the room lifetime unless overwritten or cleared. Forgetting to clear them causes late joiners to receive obsolete state. Clear cache on round reset or match end.

Failure modes

Master Client migration is automatic but not instantaneous. Logic must tolerate a brief window with no authority and handle mid-operation handoff. Avoid long critical sections that assume a stable master.

Client spoofing: a malicious client can raise events with any code and payload. Without validation, this can fake scores or moves.

Message loss and reordering: RaiseEvent is best-effort within the room. Design idempotent handling and sequence numbers for actions that must not be duplicated.

Plan limits: exceeding CCU or message rate causes throttling or disconnects. Monitor room counts and per-room event frequency.

When to change the design

Change conditions that invalidate the relay-plus-Master Client model:

• Competitive integrity requirements. Move to server-authoritative logic via Photon Server SDK or a custom backend.
• Room size grows beyond ~16-32 players with dense updates. Interest groups alone may not suffice; consider authoritative snapshots or delta compression.
• Need for persistence, anti-cheat, or cross-room state. Photon Realtime is ephemeral per room; add a separate service for persistence.
• Latency sensitivity requiring deterministic simulation. The relay model adds client-side prediction complexity.

Limitations: this note assumes Photon Realtime behavior as of general SDK knowledge. Version- and plan-sensitive behavior is flagged for verification. Do not assume current pricing or limits from memory. Verify caching options, interest group limits, and Master Client migration timing in your specific SDK version and plan.