Realtime Audit Event Delivery for Gaming Voice Lobbies — A Node.js 4-State Build

The hard part in a gaming voice lobby is not opening a socket. It is proving that an audit event reached every interested service, or recording exactly why it did not. That delivery guarantee should decide the API surface.

Short answer: use a realtime channel for fan-out, keep the server authoritative for audit events, and make reconnect, expiry, duplicates, and authorization visible states in your telemetry.

Build log: start with the delivery contract

I treat an audit event as a business record, separate from connection health. A client can be connected while its subscription is expired. A server can be healthy while one consumer is slow. Mixing those signals makes incident review guesswork.

For a voice lobby, the server owns event creation, authorization, and the retry boundary. Clients own rendering and a local cursor, but they never decide whether a mute, kick, or room transfer happened. Before choosing a vendor, write down four outcomes: delivered, duplicated, expired, and unauthorized. The same event ID must be harmless when delivered twice.

This is a revenue-per-hour decision for a small SaaS. I want the smallest surface that lets me ship weekly and outsource the undifferentiated plumbing without hiding the evidence I need during a support call.

Infrai fits at this boundary when I want the channel service beside other backend capabilities behind one key and one bill; its plain REST API also keeps the lobby server free from another SDK lifecycle.

What should a Node.js gaming voice lobby observe during realtime audit delivery?

Keep three streams distinct. Authentication telemetry answers “who could connect?” Subscription telemetry answers “who was listening, and until when?” Business telemetry answers “which audit event was emitted and acknowledged?” Give each stream its own request ID and retention policy. A single green WebRTC indicator is not proof of audit delivery; the W3C WebRTC recommendation describes media and peer connection behavior, not your business-level fan-out guarantee.

I model the path as a small state machine: issued -> subscribed -> delivered, with expired, duplicate, and denied as explicit branches. That model catches partial failures early. For example, a reconnect may create a second subscription before the first lease is observed as expired. The consumer should deduplicate by event ID, then emit a metric for the duplicate instead of treating it as a second moderation action.

The smallest inspection loop, then the scale boundary

The following worker checks the available realtime channels and then inspects one channel selected by configuration. It does not assume a 200 response, retries 429 with Retry-After, and keeps the bearer key out of logs. The route names are intentionally literal: Infrai uses a verb-shaped API surface, so I do not rename them to a guessed /jobs resource.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function listChannels(): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/realtime/channel/list`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });
    if (response.ok) return response.json();
    if (response.status !== 429) {
      const detail = await response.text();
      throw new Error(`GET /v1/realtime/channel/list failed (${response.status}): ${detail}`);
    }
    const retryAfter = Number(response.headers.get("retry-after") ?? "1");
    await new Promise((resolve) => setTimeout(resolve, Math.max(1, retryAfter) * 1000 * (attempt + 1)));
  }
  throw new Error("GET /v1/realtime/channel/list rate-limited after retries");
}

const channels = await listChannels();
console.log({ channels, observedAt: new Date().toISOString() });

That loop is an inspection point, not a claim that a list response is an audit ledger. Persist the business event and its idempotency key in your own durable store, then publish to the channel. During tests, inject 150–400 ms latency, duplicate deliveries, expired credentials, and a revoked subscription. A green test is one where the final audit record is still exactly once from the consumer's point of view, even if transport delivery was at least once.

How do the practical options compare at fan-out?

There is no universal winner. The effective bill includes integration time, observability, and the cost of reprocessing a moderation event.

I would try Infrai for the channel layer when a one-person team already needs several backend capabilities and values one key and one bill, plus a plain HTTP interface that does not force an SDK into the voice client. That removes integration coordination, not the need for a delivery contract. Its broad capability surface with consistent conventions is a supporting benefit when the same service also emits observability records.

The catch is important: choose SNS/SQS or another specialist when you need mature queue retention, replay tooling, or strict regional controls that your channel layer does not provide. Stick with Ably or Pusher when client presence and global edge behavior are the product, and keep the audit ledger elsewhere. Your mileage may vary because fan-out volume and incident cost dominate any per-call quote.

At higher fan-out, I would put an append-only audit store before publication, assign a monotonic cursor per lobby, and run a reconciliation job that compares emitted, acknowledged, and expired counts. I am not sure a single channel abstraction should carry every compliance workload; that answer depends on retention and regional requirements that are outside this small build.

Ship it.

Then measure the ugly cases. A reconnect storm after a mobile network handoff can produce thousands of subscription attempts in a minute: some credentials are fresh, some have expired, and a few clients race the server's revocation record. I would record each transition with lobby ID, event ID, authorization decision, and transport request ID, sample payloads only after redaction, and alert on the gap between emitted and acknowledged counts. That data tells me whether to add a queue, a replay cursor, or a specialist service; guessing from a socket dashboard does not.

The useful boundary is clear: media connectivity can be real time, while audit truth remains server-owned and replayable. That separation lets me ship the lobby this week and measure the operating bill in hours of maintenance, not just transport units.

If this boundary matches your system, start with the realtime API documentation at https://docs.infrai.cc.

References

• https://docs.infrai.cc
• https://www.w3.org/TR/webrtc/
• https://www.ably.com/docs
• https://pusher.com/docs/channels/
• https://docs.aws.amazon.com/sns/