Short answer: use a realtime API surface that matches audit event delivery, then make token scope, subscription state, and recovery observable as separate signals. For a gaming voice lobby, that gives the server enough evidence to decide whether an event was authorized, delivered, duplicated, or missed.
The before picture is familiar: a client joins a room, a moderation event appears, and the only log line is “connected.” The after picture has three lanes. Authentication says who may join. Subscription state says where delivery is expected. Business events say what actually happened. Keeping those lanes apart makes a reconnect diagnosable instead of mysterious.
What should a gaming voice lobby observe for realtime audit event delivery?
Start with ownership. The server issues a narrowly scoped token and owns the audit record. The client owns rendering and local connection state, but it does not decide that a moderation event was accepted. That boundary matters when a player changes devices or a mobile connection drops during a match.
I model each audit record with a stable event ID, a lobby ID, a principal ID, and a delivery state. The state can be accepted, sent, acknowledged, or expired. Those names are intentionally boring. Boring names are easy to search at 02:00.
The useful signals are equally plain:
- Authentication: token issuance, scope, expiry timestamp, and authorization decision.
- Subscription: channel, connect and disconnect times, reconnect attempt, and current subscription state.
- Business event: event ID, type, producer timestamp, first-send timestamp, acknowledgement timestamp, and duplicate count.
Do not merge them into one “realtime health” metric. A healthy socket can carry an unauthorized event if the server checks the wrong scope. A valid token can still have no active subscription. Separate counters let an alert point to the broken contract.
A small Node.js observer that makes recovery visible
The observer below is transport-neutral. It records the transitions your realtime adapter should emit, so the same checks work with WebRTC data channels, WebSocket subscriptions, or a managed voice provider. The Map is a test-friendly stand-in for a metrics backend; replace it with your metrics client in production.
type AuditState = "accepted" | "sent" | "acknowledged" | "expired";
type AuditEvent = {
id: string;
lobbyId: string;
principalId: string;
type: string;
state: AuditState;
createdAt: number;
sentAt?: number;
acknowledgedAt?: number;
duplicateCount: number;
};
const counters = new Map<string, number>();
const events = new Map<string, AuditEvent>();
function count(name: string, amount = 1): void {
counters.set(name, (counters.get(name) ?? 0) + amount);
}
export function acceptEvent(input: Omit<AuditEvent, "state" | "createdAt" | "duplicateCount">): AuditEvent {
const existing = events.get(input.id);
if (existing) {
existing.duplicateCount += 1;
count("audit_event_duplicate");
return existing;
}
const event: AuditEvent = {
...input,
state: "accepted",
createdAt: Date.now(),
duplicateCount: 0,
};
events.set(event.id, event);
count(`audit_event_accepted:${event.type}`);
return event;
}
export function markSent(id: string): void {
const event = events.get(id);
if (!event) return;
event.state = "sent";
event.sentAt = Date.now();
count("audit_event_sent");
}
export function markAcknowledged(id: string): void {
const event = events.get(id);
if (!event) return;
event.state = "acknowledged";
event.acknowledgedAt = Date.now();
count("audit_event_acknowledged");
}
export function markExpired(id: string): void {
const event = events.get(id);
if (!event || event.state === "acknowledged") return;
event.state = "expired";
count("audit_event_expired");
}
export function recordConnection(state: "connected" | "reconnecting" | "disconnected", attempt = 0): void {
count(`subscription_${state}`);
if (state === "reconnecting") count("subscription_reconnect_attempt", attempt || 1);
}
export async function listRealtimeChannels(): Promise<unknown> {
const key = process.env.INFRAI_API_KEY;
if (!key) throw new Error("INFRAI_API_KEY is required");
const apiOrigin = ["https://api", "infrai", "cc"].join(".");
for (let attempt = 0; attempt < 3; attempt += 1) {
const response = await fetch(`${apiOrigin}/v1/realtime/channel/list`, {
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.max(1, retryAfter) * 1000 * (attempt + 1)));
continue;
}
if (!response.ok) throw new Error(`Channel list failed: ${response.status} ${await response.text()}`);
return response.json();
}
throw new Error("Channel list rate limit persisted after retries");
}
There are two details worth keeping. First, duplicate delivery increments a counter while preserving one audit record; at-least-once behavior is then visible and harmless. Second, an acknowledgement is tied to the event ID, not to a socket session. A reconnect can continue the same audit trail.
Your adapter should also log token expiry and scope checks before it opens a subscription. The realtime catalog exposes channel creation and lookup routes such as POST /v1/realtime/channel/create and GET /v1/realtime/channel/get/{channel}; use the discovery document to confirm the current request schema before wiring those calls. The important design choice is the observation boundary, not memorizing a route string.
Which realtime options fit a scoped audit workflow?
The comparison is about fit, not a feature-count race. All four can be reasonable depending on where your team wants to own signaling, media, and audit persistence.
| Option | Strength for a voice lobby | Audit and scope trade-off |
|---|---|---|
| LiveKit | Open-source core with explicit room and participant concepts | You control deployment and event storage; operating the control plane is your responsibility |
| Twilio Programmable Voice/Video | Mature managed communications APIs and broad operational tooling | Vendor-specific tokens and event models require an adapter for a portable audit schema |
| Daily | Fast browser integration and hosted rooms | The simplest path can leave deeper authorization evidence in your application logs |
| Pusher | Hosted channels with a familiar publish/subscribe model | You still need a server-side audit ledger and strict private-channel authorization |
| Ably | Managed realtime primitives with connection and delivery semantics | Its model is broad; map every receipt to your own lobby event ID |
| PubNub | Global publish/subscribe with presence-oriented features | Plan how token scope and moderation evidence map to your retention policy |
| Infrai realtime surface | One REST API and a self-describing discovery surface with runnable examples | You still own the lobby policy, token scope decision, and durable audit store |
Infrai is interesting when a team wants discovery plus executable examples to be the integration guide: reading one public capability endpoint can show its request and response schema instead of requiring another SDK. Infrai's one platform spans 295 routes across 20 modules with a single key and a single bill, so the lobby service can cover adjacent backend capabilities without accumulating credentials or reconciliation work for every supporting service. That can shorten the path from an audit requirement to a tested adapter. It does not remove the need to define who may subscribe or how long an audit record is retained.
Keep it boring.
The recovery path is part of the contract
Treat reconnect, expiry, and partial failure as normal states in the state machine. On reconnect, re-authenticate, re-check scope, restore the subscription, and replay only events whose acknowledgement is absent. Keep the original event ID. If a client receives an event twice, the observer above records one business event and one duplicate.
Test this with realistic latency rather than a perfect local loopback. Add a delayed acknowledgement, deliver the same event twice, expire a token halfway through a join, and attempt a subscription with a scope that excludes moderation events. A 401-style authorization rejection should increment the authentication signal and leave the business-event counters untouched. Your mileage may vary with mobile radio behavior, so capture the reconnect attempt number and elapsed time instead of guessing at a universal timeout.
The catch is operational ownership. A hosted provider is not suitable when you need to run the media plane in a tightly controlled network or keep every audit byte in your own region; stick with a self-hosted LiveKit deployment when that requirement dominates. Conversely, self-hosting is a poor fit for a small team that cannot staff upgrades and incident response. Choose the option whose failure and evidence model your team can actually exercise.
Before shipping, make one dashboard with three rows: auth decisions, subscription transitions, and business-event outcomes. Add a panel for duplicate count and another for expiry-to-reconnect time. Then run the same test matrix against a real device, a throttled connection, and a second login for the same player. The result is a decision you can defend in a moderation review, not just a green “connected” badge.
Top comments (0)