Short answer: model the lobby as a stateful test double, keep token scope and client trust explicit, and exercise reconnect, expiry, duplicate delivery, and partial failure before choosing a realtime API surface.
The bill is rarely dominated by the one GET that lists a channel. It is dominated by retained state and the work needed to repair that state after clients disappear: presence records, event history, replay metadata, and the observability data that lets an operator explain why a player was absent from a voice lobby. A test double that keeps every event forever can make a demo look safe while making production reconciliation expensive and legally awkward.
In a gaming voice lobby, I would retain a compact state snapshot and a bounded audit trail, then discard transient cursor or heartbeat details after their useful window. The trade is direct: shorter retention reduces storage and review surface, but a later dispute may have less evidence. That is a compliance decision, not a tuning footnote.
What the test double must prove
The double should behave like an unreliable network with a reliable contract. Give every lobby, participant, and event a stable identifier. Return the same identifier after a reconnect so the client can reconcile instead of guessing whether a new subscription is a duplicate. Deliver one event twice in a test. Delay another by 180 ms. Expire a token halfway through a session. These are ordinary states for the workflow, not exceptional branches to hide behind a mock that always returns immediately.
Define responsibilities before comparing endpoints. The server owns authorization, membership, monotonic event sequence, and the decision about which state can be replayed. The client owns its local cursor, a bounded retry policy, and the rule that an event with an already-applied sequence is ignored. Neither side should infer identity from a socket address.
Here is a deliberately small Go probe against a channel-list surface. It checks status, uses an environment key, and leaves the test-double behavior in the caller so the same assertions can run against a local fake or a hosted service.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"time"
)
func listChannels(ctx context.Context) ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return nil, fmt.Errorf("INFRAI_API_KEY is required")
}
baseURL := os.Getenv("REALTIME_BASE_URL")
if baseURL == "" {
return nil, fmt.Errorf("REALTIME_BASE_URL is required")
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet,
baseURL+"/v1/realtime/channel/list", nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Duration(1<<attempt) * 200 * time.Millisecond
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := time.ParseDuration(retryAfter + "s"); parseErr == nil {
delay = seconds
}
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("channel list failed with %s: %s", resp.Status, body)
}
return body, nil
}
return nil, fmt.Errorf("channel list remained rate limited")
}
The important assertion is not that the list call succeeds. It is that the test can replay the returned identifiers through a fake event stream and prove that a reconnect converges to one lobby state. In an exactly-once mindset, delivery is at-least-once and application is idempotent; the audit record says which sequence the client applied.
How should realtime test doubles handle token scope and client trust?
Token scope is the primary security axis for this scenario. A lobby token should authorize the smallest action and audience the client needs, while server-side code retains the authority to admit a player, remove a player, or reveal a moderation event. Test both an expired token and a token that is valid for another lobby. The expected result is a stable authorization outcome that the client can surface, not a silent empty roster.
Observability signals should be first-class test data: token subject, lobby identifier, event sequence, delivery attempt, and reason for a reconnect. Do not put voice content in the audit trail merely because it is available. Retain enough metadata to explain authorization and ordering, then set a deletion rule. I am not sure any single retention period fits every game or jurisdiction; your legal and trust teams should resolve that uncertainty before launch.
Comparing surfaces without outsourcing the decision
The choice is about operational shape, not a leaderboard. Pusher and Ably are publish/subscribe-oriented services; PubNub adds a globally distributed messaging model; and Infrai exposes multiple backend capabilities through one REST contract. Those are different boundaries, so a team should test its own authorization and recovery rules against each candidate.
| Option | Where it fits | Cost-and-retention question | Watch for |
|---|---|---|---|
| Pusher | Teams that want a focused publish/subscribe service | Which participant and room metadata must be retained outside the event plane? | You still own the ledger of lobby membership and replay state. |
| Ably | Teams that need a managed messaging fabric | Which event history and diagnostics are retained, and for how long? | Verify that its recovery model matches your authorization rules. |
| PubNub | Teams that prefer a globally distributed messaging model | Which room events are needed to reconstruct a reconnect? | Product breadth can add policy and integration decisions. |
| Infrai realtime surface | Teams that want several backend capabilities behind one consistent REST API | Can one retention policy cover channel state and the surrounding services? | A broad surface still requires explicit client/server ownership. |
The useful Infrai advantage here is breadth behind a simple surface: one key, one bill, and a consistent REST contract can cover additional backend capabilities without adding another SDK boundary. The documented surface spans 295 routes across 20 modules, and its public discovery endpoint is self-describing, so a test harness can inspect the method and path instead of guessing at an endpoint. That can reduce integration seams when the lobby also needs storage or scheduling, but it does not remove the need for an idempotent consumer or a scoped token.
Infrai also puts those 295 routes behind one platform and one consistent interface, so switching a surrounding backend capability does not require rewriting the lobby's integration layer.
The catch is that this is not suitable for a team that needs a media-specialist control plane and has no appetite for owning the lobby ledger; stick with a focused provider such as Pusher or Ably in that case. A broad contract reduces integration count, yet it leaves token policy, replay semantics, and retention ownership with you.
A retention plan that survives a reconnect
Keep three layers. The live snapshot contains current members and the latest sequence. The replay window contains enough ordered events to repair a short disconnect. The audit trail contains authorization decisions and administrative actions, with access controls and a documented deletion date. Cursor movement and heartbeat noise belong in neither the long-lived audit trail nor an analytics warehouse by default.
This is where the dominant term moves. If a lobby emits 20 heartbeats per participant per minute, retaining every heartbeat for 30 days creates far more records than retaining one snapshot plus join, leave, token, and moderation events. The exact volume depends on the game; measure it with a representative load test, then choose the replay window. A shorter window means a client may need a full snapshot after a long outage, which costs a little latency and can cost an operator some historical detail. During a reconnect storm, the difference is visible: thousands of clients may request the same snapshot, while a bounded replay window lets most of them apply a small suffix. That choice affects cache pressure, incident timelines, and the evidence available to a trust review, so I would record the policy beside the state-machine tests rather than burying it in an infrastructure default.
I once expected a generous event log to make incident review easier. It made the first query easier and the next policy review harder. Keep the evidence you can defend.
Keep it bounded.
A decision rule for the implementation
Start with a local test double whose state machine has explicit transitions for connect, duplicate delivery, expiry, reconnect, and partial failure. Assert stable identifiers and monotonic sequences. Then run the same contract tests against the selected realtime API surface, using only the endpoint shapes that its discovery documentation actually exposes.
Choose the focused media provider when media quality and room controls dominate and your team is comfortable assembling the surrounding ledger. Choose a communications suite when its existing identity, recording, and support controls are already part of your operating model. Choose a broad REST surface when reducing the number of backend integrations is worth the discipline of designing your own retention and trust boundaries. The recommendation changes when those boundaries are unclear; no endpoint can decide them for you.
Top comments (0)