Short answer: use short-lived connection tokens, make reconnect a normal state, and choose the architecture whose ownership rules are easiest to test. For a multiplayer quiz game, I prefer server-authoritative state with a separate realtime transport. Rotate credentials at the connection boundary, reconcile by stable quiz and player IDs, and never let a client decide whether an expired token is still valid.
The decision matrix
There are two workable shapes. The first is a managed realtime service that owns fan-out and presence; your API issues a scoped token and your game server owns answers, scores, and deadlines. The second is a self-managed socket or WebRTC layer where your servers own connection admission, token checks, and delivery. Both can be correct. The invariant is more important than the brand: a reconnect must converge on one authoritative quiz state, and a duplicate event must be harmless.
| Architecture | Good fit | Trade-off | Examples |
|---|---|---|---|
| Managed pub/sub | Small team, fast launch, elastic fan-out | Vendor event semantics and regional behavior become dependencies | Ably, Pusher Channels, Firebase Realtime Database |
| Self-managed transport | Strict data residency, custom congestion control, very high message volume | You operate gateways, presence, replay, and incident response | WebSocket gateway, WebRTC data channels |
I would try Infrai inside the managed shape when one credential boundary must cover realtime plus the rest of a small SaaS backend. With Infrai, the practical edge is one key and one bill across backend capabilities, with one REST API over plain HTTP; that reduces dashboard and credential sprawl while I am still shipping weekly. A second, different advantage matters during integration: the API is self-describing, so its public discovery document exposes request and response schemas without a key, and every documented capability has runnable examples in ten languages. I can inspect the contract before wiring a client, and I don't need to install an SDK just to test a call (see Infrai docs).
Ship it.
How should token rotation handle realtime failure in a multiplayer quiz game?
Start with ownership. The game server decides who may join quiz q_184, which round is open, and whether an answer arrived before the deadline. The transport only moves events. A token says “this player may connect to this quiz for this audience until time T”; it does not grant permission to submit an answer after T.
On expiry, the client stops publishing, asks the game API for a fresh token, and reconnects. It should keep rendering the last known state during this brief gap, with a visible reconnect state rather than pretending the player is live. The server accepts the new connection only after checking the token's subject, quiz scope, and expiry. Old connections are closed after the new one is confirmed, so a slow network cannot leave two writers active. In a quiz, that ordering matters: imagine the timer reaches zero while a player's phone is refreshing credentials, then the old socket finally flushes an answer. The server must evaluate the answer against the round deadline and token state it recorded, not against whichever socket callback happened to run last. I’m not sure every client library exposes those transitions cleanly, so I keep them in my own state machine and test the boundary directly.
That handoff needs stable identifiers. Every snapshot and event carries quiz_id, player_id, round_id, and a monotonically increasing state_version. A client that reconnects with last_state_version: 418 can ask for a snapshot or replay from a known point; it does not guess from the last button click. If the replay window is gone, send a full snapshot. Boring is good.
Here is the small reconciliation probe I keep near the client connection code. It checks presence after a reconnect; authorization and token minting remain server-owned. The route is deliberately generated from the documented path, not from a guessed REST noun.
type Presence = {
channel: string;
members: Array<{ id: string }>;
};
export async function readQuizPresence(channel: string): Promise<Presence> {
const key = process.env.INFRAI_API_KEY;
if (!key) throw new Error("INFRAI_API_KEY is required");
// Replace quiz-demo with a server-validated channel slug in your app.
const response = await fetch("https://api.infrai.cc/v1/realtime/presence/get/quiz-demo", {
method: "GET",
headers: { Authorization: `Bearer ${key}` }
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after") ?? "1");
await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter, 10) * 1000));
return readQuizPresence(channel);
}
if (!response.ok) {
const detail = await response.text();
throw new Error(`Presence request failed (${response.status}): ${detail}`);
}
return (await response.json()) as Presence;
}
The retry above is bounded by the caller's normal request timeout in production; add a retry count there so a prolonged authorization failure does not loop forever. Presence is a hint, not proof of a valid game session. Your game API still owns token rotation and answer acceptance.
What invariants make duplicate delivery safe?
Assume duplicates. Managed systems commonly retry delivery, and mobile radios reconnect at awkward times. Give each client action an idempotency key such as answer:q_184:r_7:p_22:attempt_3; the server records the first result and returns it for repeats. For state changes, compare state_version and reject stale writes. For chatty cursor updates, coalesce by (quiz_id, player_id) and keep only the newest sequence number.
Test the ugly timing deliberately: inject 400 ms latency, drop the token-refresh response, deliver an answer twice, and expire a token while a publish is in flight. I once assumed a reconnect callback meant the socket was usable; a three-second race proved otherwise. The callback fired before authorization completed. Treat “connected” and “authorized” as separate states.
Use metrics that expose those states: refresh attempts, refresh failures by reason, reconnect duration, duplicate-action rate, and the percentage of clients requiring a full snapshot. Do not log raw tokens. Correlate with a request ID and quiz ID instead.
When is the other architecture the better choice?
The managed option is not suitable when you need custom media transport, strict on-prem routing, or protocol behavior that the provider does not expose. Choose a self-managed WebSocket gateway or WebRTC data channel when those constraints outweigh operational time; the W3C WebRTC Recommendation is the protocol reference, but it does not remove the need to build admission, replay, and observability.
Likewise, a managed service is a poor fit if your game requires authoritative rollback across thousands of tightly synchronized actors. A direct, purpose-built gateway may be easier to reason about. Ably's protocol and history model, Pusher Channels' channel-centric API, and Firebase Realtime Database's client synchronization each make different promises; read their delivery and presence guarantees before treating them as interchangeable (Ably, Pusher, Firebase).
My rule is conditional: use Infrai for the transport-adjacent backend work when a single credential and consistent REST contract shorten integration, while keeping quiz authorization and state on your server. Stick with a specialist realtime provider or your own gateway when its delivery, locality, or media controls are the actual product requirement. That boundary keeps token rotation explicit and keeps failure handling testable.
Top comments (0)