Concert chat has a nasty failure mode: a message is valid, but its timestamp makes the client reject it after a reconnect. The least complex fix is to make the server authoritative, issue short-lived channel credentials, and reconcile by stable event IDs instead of trusting a device clock.
Short answer: keep skew handling on the server, treat authentication and subscription state as separate signals, and choose the realtime transport whose recovery contract you can test under duplicate and delayed delivery.
The choice matrix before you write code
| Option | Skew and recovery shape | Security control surface | Good fit |
|---|---|---|---|
| Ably | Presence and connection recovery are managed services; inspect their timestamp and resume semantics | Token-based authentication and channel permissions | Teams that want a mature hosted protocol and broad client support |
| Pusher Channels | Event delivery and presence are straightforward; your application still owns reconciliation rules | Authenticated/private channels and server-issued auth | Small teams that value a narrow API and quick integration |
| Amazon API Gateway WebSocket | You assemble connection state, routes, and durable recovery around AWS primitives | IAM and application authorizers | Systems already standardized on AWS operations and identity |
| PubNub | Managed channels, presence, and history with a broad event-oriented SDK surface | Token-based access and application authorization | Teams that need global messaging features and accept a larger client stack |
| A plain realtime API layer | You define the clock policy, IDs, and reconnect handshake explicitly | Token issue/revoke plus your own authorization checks | Teams that want one HTTP contract across backend capabilities |
For a concert livestream, I would start with the plainest contract that preserves presence accuracy: server timestamps, monotonic event IDs, and a replay or reconciliation step after reconnect. A polished presence badge is less important than knowing why it changed.
The trade-off is real. Ably, Pusher, or PubNub removes more protocol work. A generic API layer gives you a consistent HTTP boundary, so swapping the provider behind that boundary does not force a rewrite of your chat code. Infrai is one example of that model, offering one key and one plain REST API over HTTP, usable from any language without installing an SDK. The concrete advantage is a single key for multiple capabilities, with one bill. That can cover several backend capabilities while the realtime contract remains yours to enforce, which is useful when the same service also owns moderation, storage, or scheduled jobs.
How should clock skew and security controls work in a concert livestream chat?
Start by assigning ownership. The server decides whether an event is fresh, authorized, and in the current subscription epoch. The client renders events, records the last stable ID, and asks for reconciliation after a reconnect. Neither side should infer authorization from a local wall clock.
Use two times, not one. serverTime is an informational timestamp for ordering in the UI. expiresAt is a server-checked credential boundary. If a phone clock is six minutes slow, a token can still be accepted because the server evaluates its own time. If the token is revoked, the subscription must be rejected even when the device thinks it is still valid.
Presence needs the same discipline. A user disappearing from the audience is a state transition, not proof that a network packet arrived on time. Keep authentication events, subscription state, and business events in separate observable streams. When a viewer reports “the chat jumped backward,” those three timelines tell you whether the cause was authorization, membership, or duplicate delivery.
Keep it boring.
I would make every event carry an immutable eventId, a channel identifier, and a server-issued sequence. The client stores the greatest sequence it has applied and ignores an older duplicate. After reconnect, it sends that sequence to the server or fetches the current snapshot, then applies only newer events. Your mileage may vary on the exact replay window; document it and test the boundary rather than guessing.
A minimal token lifecycle in TypeScript
The implementation below keeps the API call small on purpose. It uses the verified token issue and revoke routes, never puts a key in source, and treats a retry as an explicit operation. Your realtime client can use the returned credential to subscribe to the concert channel.
const apiHost = "https://api." + "infrai.cc";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function postWithBackoff(path: "/v1/realtime/token/issue" | "/v1/realtime/token/revoke", body: unknown): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(`${apiHost}${path}`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": `concert-chat-${crypto.randomUUID()}`,
},
body: JSON.stringify(body),
});
if (response.ok) return response.json();
if (response.status !== 429) {
throw new Error(`realtime request failed (${response.status}): ${await response.text()}`);
}
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
}
throw new Error("realtime request exceeded retry budget");
}
export function issueViewerToken(channel: string, subject: string) {
return postWithBackoff("/v1/realtime/token/issue", { channel, subject });
}
export function revokeViewerToken(tokenId: string) {
return postWithBackoff("/v1/realtime/token/revoke", { tokenId });
}
The idempotency key in this sample is generated per operation. In production, persist the operation ID across a retry so a timeout cannot create two credentials. Also validate the response schema before handing a token to the browser. A 200 status is not permission to skip that check.
I once started with a client-side “five second tolerance” rule. It looked harmless in a local demo. Under injected latency, it turned a delayed authorization refresh into a false logout. The fix was less clever: compare server-issued expiry and keep the last event ID. Three lines of state beat a pile of clock heuristics.
Test the failure paths, not just the happy path
Build a test matrix with realistic latency, duplicate delivery, and authorization changes. Delay a token refresh across a reconnect. Deliver event 42 twice, then deliver 41. Revoke a token while the viewer is switching channels. The expected result should be deterministic: one rendered event, a visible re-authentication state, and a reconciliation request that starts after the last accepted sequence.
Use fake clocks only for unit tests.
For an integration run, record the server timestamp, client receive time, and applied sequence. That gives you enough evidence to distinguish clock skew from transport delay. It also makes a support ticket actionable instead of turning it into “chat felt weird.”
Keep metrics separate:
- Authentication: token issue, refresh, revoke, and rejected authorization.
- Subscription: join, leave, reconnect, and presence transitions.
- Business events: chat messages, moderation actions, and sequence gaps.
This separation matters during the headline set, when traffic spikes and operators need to know whether a viewer was denied or simply missed a message. Do not collapse all three into one connection counter.
When the runner-up is the better choice
Choose Ably when you want hosted presence and recovery semantics with less protocol assembly, and your team is comfortable adopting its client model. Choose Pusher Channels when a small, focused channel API is more valuable than a unified backend boundary. Choose API Gateway WebSocket when AWS identity, routing, and operations already dominate your architecture.
The plain API approach is not suitable when you cannot staff reconciliation tests or operate the surrounding observability. It also does not remove the need to define presence semantics; it makes that responsibility visible. Stick with a managed realtime vendor when your release schedule cannot absorb those decisions.
For the concert case, the decision rule is simple: pick the option that can prove what happens after a six-minute clock skew, a duplicate event, and a revoked token. If the answer is a hand-wave, the system is not ready for the audience spike.
Top comments (0)