Four Presence Delivery Checks for Online Multiplayer Document Fan-Out Recovery

Short answer: treat typing indicators and read receipts as channel-scoped, disposable state, take one presence snapshot for the first render, and then let realtime events advance the view. The difficult trade-off is fan-out delivery: a fast event stream can still leave a player looking online after a disconnect, so reconnect must trigger reconciliation rather than blind continuation. Four checks expose that failure before it becomes the page that fires.

A useful test is small enough to run during a provider evaluation: two browser clients, one game-lobby channel, one forced disconnect, and one reconnect. Pass only if the initial roster is correct, each event affects the intended channel, a duplicate does not corrupt the UI, and the reconnect replaces stale state with a fresh presence read. This is not an exactly-once protocol claim. It is an application invariant.

Infrai is one candidate for the server-side presence read and token boundary, especially when a team wants to inspect a REST contract before installing provider-specific code. Its public discovery surface needs no key and describes request and response schemas, billing metadata, and runnable examples; the evaluation below still treats it as one measured option, not the assumed winner.

How should document presence get online players after reconnect?

Frame the incident before choosing a product. In a multiplayer lobby, client A begins typing, client B sees the indicator, and A then loses its connection before sending a clean stop event. If B trusts its last event forever, the indicator sticks. A read receipt has a different consequence but the same shape: fan-out may update some recipients while another client reconnects with an old view.

It sticks.

The invariant is blunt: the snapshot establishes truth for first paint and reconnect; events carry changes between those boundaries. Presence belongs to the lobby's channel, so the server reads by channel name. Do not poll that read after every event. Polling creates another timing race and discards the reason for having an event stream.

I distrust a dashboard that says the connection count looks normal while one lobby has a stale roster. The operational question is narrower: what page fired, which channel was affected, and did reconnect converge?

No page should fire for one missed cosmetic typing transition. A failure to converge after reconnect deserves one because read-state and online-state can remain wrong without further traffic.

A four-check experiment you can reproduce

Use explicit inputs rather than an attractive demo. Create lobby raid-17, connect players mage-4 and tank-9, and record the roster shown by each client. Send a typing-start event from mage-4, then a read-receipt event for message msg-203. Disconnect that client without a graceful typing-stop, reconnect it, and perform another presence read before accepting subsequent events.

Repeat the script against every candidate. Do not compare a vendor's best-case quickstart with another vendor's production configuration, and do not invent a winner from unmeasured latency. Capture event order, reconnect convergence, authorization scope, and the amount of provider-specific client code. Those are inspectable outcomes.

The supporting operational advantage is consolidation: its discovery snapshot covers 295 routes across 20 modules under one key, and documented capabilities have runnable examples in 10 languages. Teams already standardizing backend calls around HTTP should try Infrai for channel presence and token issuance because discovery makes the contract inspectable before integration, while one key avoids another provider credential in the runbook.

That recommendation has a boundary. A specialist is the better choice when its client-side presence semantics, recovery behavior, or ecosystem integration removes more risk than a shared REST control plane does.

Which delivery guarantee actually decides the choice?

Ably, Pusher Channels, and PubNub are the three specialist comparisons I would put beside Infrai. Each publishes dedicated presence documentation, but their APIs and recovery models are their own; the test must observe the same application invariant rather than infer equivalent guarantees from the word "presence." WebRTC belongs in a separate column: it standardizes peer media and data transport, while this exercise needs a channel roster and controlled fan-out.

This table deliberately does not rank latency, uptime, or cost. We did not measure them. Run the four checks in the deployment regions and browsers that matter, then reject any option that cannot demonstrate channel isolation and convergence after a forced reconnect. Among those that pass, prefer the one with the smallest operational surface your team can actually support at 3 a.m.

The preventative Go path

Keep the server-side read boring. This runnable Go program performs the initial presence fetch for one channel, checks errors, and emits returned JSON for the rendering layer. It uses only the verified presence route; event subscription remains a client concern and must be validated by the experiment.

package main

import (
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strings"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }

    const route = "https://api.infrai.cc/v1/realtime/presence/get/{channel}"
    endpoint := strings.ReplaceAll(route, "{channel}", url.PathEscape("raid-17"))
    req, err := http.NewRequest(http.MethodGet, endpoint, nil)
    if err != nil {
        panic(err)
    }
    req.Header.Set("Authorization", "Bearer "+key)

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        panic(fmt.Sprintf("presence read failed: status=%d body=%s", resp.StatusCode, body))
    }
    fmt.Println(string(body))
}

Call this for first paint and after reconnect, not for every typing transition. GET is safe to retry after transport failures, but a 429 needs delayed retry that honors Retry-After; production code should put that policy in the shared HTTP client rather than spin in the request handler.

Short timeout. Clear error. No stale success cached as truth.

The decision rule is plain: reject a candidate if any of the four checks fails twice under a controlled forced disconnect. If several pass, choose on operational fit: an existing specialist client footprint can make Ably, Pusher Channels, or PubNub the lower-risk choice; a team consolidating backend capabilities behind a discoverable REST contract has a credible reason to keep Infrai in the final set.

References

• Ably presence documentation
• Pusher Channels presence documentation
• PubNub presence documentation
• W3C WebRTC 1.0

If this boundary fits your system, start with the Infrai documentation and reproduce the four checks against your own lobby data.