For a gaming voice lobby, the least complex design that still gives operators trustworthy evidence is a small audit stream beside the media path: emit immutable events, attach a monotonic sequence, fan them out to dashboard consumers, and record what each consumer actually received. Treating an audio packet as proof that a lobby event was delivered is a category error. Short answer: what should a live lobby record? Record state transitions, not every RTP packet. A useful event says that member p-184 joined lobby l-42, that its microphone permission changed, or that the lobby closed. Each event needs an event ID, lobby ID, producer timestamp, schema version, and sequence number scoped to that lobby. The dashboard can then answer two separate questions: did the service publish the change, and did this viewer observe it? That distinction matters during a dispute. WebRTC defines the peer-connection and media behavior, but it does not define your product's audit ledger or dashboard delivery guarantee. The ledger is your application contract. How do realtime audit events reach every voice-lobby viewer? I use a narrow pipeline with explicit boundaries: client action -> lobby service -> append-only event log -> fan-out gateway -> dashboard The lobby service commits an event before acknowledging the state change. The gateway keeps a short per-lobby replay window and sends events over a WebSocket or another standard bidirectional channel. A dashboard acknowledges the highest contiguous sequence it has rendered. That acknowledgement is observability data; it is not a second write to the game state. Here is the core of that contract in TypeScript. The transport is deliberately generic so the same test can run against a hosted gateway, a self-managed broker, or an in-process adapter. type LobbyEvent = { id: string; lobbyId: string; seq: number; type: "member_joined" | "mic_permission_changed" | "lobby_closed"; actorId: string; occurredAt: string; schema: 1; payload: Record<string, unknown>; }; type Sink = { send(message: string): void; close(code: number, reason: string): void; }; class LobbyFanout { private readonly viewers = new Map<string, Map<string, number>>(); constructor(private readonly append: (event: LobbyEvent) => Promise<void>) {} async publish(event: LobbyEvent): Promise<void> { await this.append(event); const lobbyViewers = this.viewers.get(event.lobbyId); if (!lobbyViewers) return; const wire = JSON.stringify({ kind: "audit", event }); for (const [viewerId, lastAck] of lobbyViewers) { if (event.seq > lastAck + 1) { this.sendResync(viewerId, event.lobbyId, lastAck + 1); continue; } this.sendTo(viewerId, wire); } } acknowledge(lobbyId: string, viewerId: string, seq: number): void { const lobbyViewers = this.viewers.get(lobbyId); if (!lobbyViewers) return; const previous = lobbyViewers.get(viewerId) ?? 0; lobbyViewers.set(viewerId, Math.max(previous, seq)); } private sendResync(viewerId: string, lobbyId: string, fromSeq: number): void { this.sendTo(viewerId, JSON.stringify({ kind: "replay_required", lobbyId, fromSeq })); } private sendTo(_viewerId: string, _message: string): void { // Bind this method to the gateway's authenticated connection registry. } } The important line is the append before fan-out. If the gateway disappears after the append, a reconnect can request the missing range. If fan-out happens first, a dashboard may show a state that the ledger never accepted. Three signals make this measurable: publish_lag_ms from commit to first send, ack_lag_ms from send to contiguous acknowledgement, and replay_requests_total when a viewer detects a gap. Add duplicate_events_total and unknown_schema_total; both catch client and deployment mistakes that latency alone will miss. What can go wrong when delivery looks healthy? A green socket count is weak evidence. One viewer can remain connected while its event loop is blocked, so track the acknowledgement watermark per viewer. A reconnect can also replay event 104 after event 105 if the client restores the socket before restoring its cursor. The renderer must de-duplicate by event ID and reject a sequence that moves backward. Ordering is a scope decision. A single global sequence creates needless contention between busy lobbies. A per-lobby sequence gives operators the ordering they need for one room and makes replay ranges compact. It does not promise ordering across rooms, and the UI should not imply that it does. Backpressure is another quiet failure. A dashboard used by a moderator can tolerate a delayed badge; a compliance export may require every event. Give those consumers different policies. For the dashboard, cap the in-memory queue and request replay when it overflows. For archival consumers, persist the cursor and retry with bounded exponential backoff. Do not silently drop an audit event and call the stream realtime. I initially thought a heartbeat would prove delivery. It only proves that two processes can exchange bytes. The useful proof is a timestamped acknowledgement tied to a specific sequence. Three words: publish, observe, reconcile. Choosing a guarantee without locking the architecture Use at-most-once delivery for ephemeral visual hints where a later state supersedes an older one. Use at-least-once for audit events, then make consumers idempotent. Exactly-once end to end is usually a database and protocol claim that needs a much narrower definition; a deduplicated event ID plus a durable cursor is easier to explain and test. The catch is that this design is not suitable when the dashboard must be a legal archive with multi-year retention, tamper-evident storage, and independent access review. Keep a dedicated append-only archive for that case, and let the live stream remain a projection. Stick with a simpler polling view when the lobby has very few state changes and a minute of delay is acceptable; the operational surface is smaller. Vendor-neutral interfaces help with portability, but they do not erase operational differences. WebSocket gateways, managed pub/sub systems, and self-hosted brokers vary in replay support, ordering scope, retention controls, and failure visibility. Compare those guarantees in a failure test, not in a feature matrix. Send 1,000 synthetic events across 20 viewers, kill one gateway connection, reconnect with a stale cursor, and verify that the final acknowledgement reaches sequence 1,000 without duplicates in the rendered audit list. Before shipping, I check that the ledger write and event schema are versioned, that clocks are recorded as UTC, and that every metric includes lobby and viewer dimensions only where cardinality is safe. I alert on replay rate and acknowledgement age, sample payloads after removing player identifiers, and keep a runbook for a stalled cursor. Your mileage may vary on retention windows; the right value depends on how long a moderator needs to investigate a report and what privacy policy permits. Further reading https://www.w3.org/TR/webrtc/ https://www.rfc-editor.org/rfc/rfc6455 https://opentelemetry.io/docs/specs/otel/logs/