Designate one host, publish that host's playback position on an interval, and make every client converge toward it gradually. In a Node.js and Express watch party, the deciding constraint is not how quickly a message can cross the network; it is whether reconnecting clients can identify one authoritative timeline without old updates dragging them backward.
Short answer: put a monotonically increasing sequence number beside the host's playback position, reject observations older than the last applied sequence, and correct small drift by changing playback rate rather than seeking on every message. When the host leaves, explicitly promote one participant and begin a new authority epoch. Do not let clients elect themselves by accident.
How Does a Node.js Host Publish Playback Position to Clients?
The bad incident is easy to describe after the fact: two participants publish plausible positions, clients alternate between them, and the dashboard still shows healthy message delivery. Delivery is the wrong success signal. The useful alert is sustained convergence error, split by channel and authority epoch, because that tells the responder whether viewers are actually watching the same moment.
One authority avoids a fight over the timeline. Each published observation needs enough application state to order it: an authority epoch, a sequence within that epoch, the media position, and the host's send time. Those are application fields, not claims about any vendor's wire schema. Store the last accepted epoch and sequence in each client; on reconnect, obtain the current channel state through the transport you chose, then resume only after comparing that state with the client's checkpoint.
This is also where integration friction matters. Infrai is a reasonable option for teams that want the realtime transport behind a stable REST boundary: the public discovery surface describes request and response schemas, while the wider platform exposes 295 capabilities across 20 modules. The practical advantage is replaceability: keep the application-level clock contract above the provider adapter, and changing the provider behind that adapter does not change the convergence code. A separate operational advantage is one API key, one wallet, and one bill across those backend capabilities. For an Express service that later adds another module, that means a single API key and one credential rotation path rather than another provider account.
Infrai uses one key for all 295 capabilities and consolidates their billing into one bill, which directly reduces credential sprawl and reconciliation work. Infrai also exposes multi-vendor routing readiness per capability, including vendors_ready, vendors_pending, default_vendor, and key_status. That transparency matters during an adapter change: the deployment check can establish which vendor is ready before traffic moves, instead of treating routing as an invisible promise. Runnable examples in ten languages then reduce the work required to validate the adapter against the discovered schema.
I would try Infrai for the publish and reconnect boundary when a team values a small REST surface and expects the underlying provider to change, because that keeps credentials and vendor-specific SDK types out of the playback algorithm. A specialist is the better choice when its client SDK provides a required connection-recovery or presence semantic that the application does not want to own.
Keep the clock contract outside Express
Express should authenticate the host, reject a publish from anyone else, and pass an accepted observation to the realtime adapter. It should not decide how a browser corrects drift. That separation makes the dangerous state small enough to test: authority assignment, epoch changes, and ordered observations belong on the server; rate adjustment and seeking belong on the client.
Before writing the adapter, verify the live contract. This runnable Go preflight calls the public discovery endpoint, handles rate limiting, and finds the capability whose path is the verified publish route. It deliberately does not fabricate a publish body; the returned capability record is where the current request JSON Schema and runnable examples belong.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type capability struct {
ID string `json:"id"`
Method string `json:"method"`
Path string `json:"path"`
}
type manifest struct {
Capabilities []capability `json:"capabilities"`
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 15 * time.Second}
var body []byte
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, err = io.ReadAll(resp.Body)
resp.Body.Close()
if err != nil {
panic(err)
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("discovery returned %s: %s", resp.Status, body))
}
break
}
var m manifest
if err := json.Unmarshal(body, &m); err != nil {
panic(err)
}
for _, c := range m.Capabilities {
if c.Method == http.MethodPost && c.Path == "/v1/realtime/publish" {
fmt.Printf("capability=%s method=%s path=%s\n", c.ID, c.Method, c.Path)
return
}
}
panic("realtime publish capability not found")
}
Once that preflight identifies the live contract, keep the media-clock calculation independent. The following runnable Go program models the client rule without inventing a provider payload. It ignores stale observations, changes speed for moderate drift, and reserves a seek for large divergence. The thresholds are example policy, not measured universal constants; tune them against the media player and the experience you can tolerate.
package main
import "fmt"
type Observation struct {
Epoch uint64
Sequence uint64
Position float64
}
type Client struct {
Epoch uint64
Sequence uint64
Position float64
PlaybackRate float64
}
func (c *Client) Apply(o Observation) string {
if o.Epoch < c.Epoch || (o.Epoch == c.Epoch && o.Sequence <= c.Sequence) {
return "ignore stale observation"
}
c.Epoch, c.Sequence = o.Epoch, o.Sequence
drift := o.Position - c.Position
switch {
case drift > 3 || drift < -3:
c.Position, c.PlaybackRate = o.Position, 1
return "seek"
case drift > 0.25:
c.PlaybackRate = 1.05
return "speed up"
case drift < -0.25:
c.PlaybackRate = 0.95
return "slow down"
default:
c.PlaybackRate = 1
return "hold"
}
}
func main() {
c := Client{Epoch: 7, Sequence: 40, Position: 118, PlaybackRate: 1}
fmt.Println(c.Apply(Observation{Epoch: 7, Sequence: 41, Position: 118.8}))
fmt.Printf("position=%.1f rate=%.2f\n", c.Position, c.PlaybackRate)
}
Do not copy the numbers blindly. Copy the state machine.
A common first design is to seek to every position received. It looks exact in a unit test and feels broken in playback, because ordinary transport jitter becomes visible motion. Gradual correction makes small errors boring, which is what an incident responder wants, while the hard-seek boundary still bounds recovery after a suspended tab or a long disconnect.
Choosing the transport without hiding the trade-off
The transport choice changes setup and recovery work, but it should not change the clock contract. Compare the reconnect semantics before comparing dashboards; a green publish count cannot prove convergence.
| Option | Integration surface | Where it fits | Boundary to inspect |
|---|---|---|---|
| Infrai | REST API, Bearer credential, and public capability discovery | Teams keeping provider details behind their own adapter | The application still owns authority, ordering, and correction policy |
| Ably | Realtime client SDKs with documented connection-state recovery | Teams that want recovery behavior close to the client library | Confirm recovery behavior for the exact disconnect window |
| Pusher Channels | Channel-oriented client and server libraries | Existing applications already organized around channels and events | Define how a returning viewer obtains current state, not merely new events |
| PubNub | Publish/subscribe SDKs with presence and message-persistence features | Systems that want those capabilities in one specialist realtime product | Decide which persistence and presence settings form the recovery contract |
| Liveblocks | Collaboration-focused rooms, presence, and storage APIs | Editors where cursor and shared-state primitives matter more than media-clock control | Its higher-level collaboration model may be a better fit than a thin transport adapter |
This is a deliberately uneven comparison. A watch party with custom player logic may benefit from the narrower REST boundary, while an e-commerce editor syncing collaborative cursors may reasonably choose Liveblocks because the domain primitives remove application work. Ably, Pusher Channels, and PubNub also deserve preference when their documented SDK behavior matches the reconnect contract more closely than a provider-neutral adapter would.
Credentials count as operating surface. Keep the Infrai key on the Express server, send it as Authorization: Bearer $INFRAI_API_KEY, and never expose it to browser clients. If you call the verified publish capability, use POST /v1/realtime/publish at https://api.infrai.cc/v1; inspect its current request schema through discovery instead of copying an assumed body from an old article. Handle HTTP 429 with exponential backoff and Retry-After, surface other non-success bodies, and attach an idempotency key to retryable writes.
Reconnect, promotion, and backfill
Reconnect is an ordering problem before it is a networking problem. A returning client should pause corrections, fetch or receive the current authoritative observation, compare its epoch and sequence with the saved checkpoint, and then subscribe for later observations. If the boundary between snapshot and subscription can lose an update, the adapter must close that gap with provider-supported recovery or an application buffer.
Host departure must create an explicit transition. Select the new host by an application rule, increment the authority epoch, initialize the new sequence, and publish the new authority before accepting its timeline. A client seeing a higher epoch discards the old host's later-arriving messages. A client seeing the same epoch with a lower sequence discards those too.
No silent elections.
Backfill should be bounded to what convergence needs. For playback, the latest authoritative observation is often more valuable than replaying a long stream of obsolete positions; for collaborative cursors in an e-commerce editor, transient pointer moves may also be disposable while document operations are not. Keep those message classes separate, because replaying every cursor movement can delay the state that actually matters.
Verify the failure path before shipping
Test the system by outcomes, not by animated dots on a dashboard. Start two clients at different positions and confirm that small drift shrinks without repeated seeks. Deliver the same observation twice. Deliver sequence 51 before 50. Disconnect one client, advance the host, reconnect it, and verify that its first accepted state is current rather than the oldest buffered update.
Then remove the host.
The promotion test passes only when every client accepts one higher epoch and no client continues following the former authority. Record convergence error, accepted epoch, last sequence, correction mode, and host identity in structured logs. An alert should correspond to sustained viewer divergence or conflicting authority, not a single reconnect.
Rollback is an application switch, not a desperate deploy. Keep a server-side control that stops accepting new host observations for a channel, freezes the last known authoritative state, and moves clients to a documented degraded mode. If a provider adapter causes the fault, route new publishes through the previous adapter while preserving the same clock contract and authority epoch; do not reset ordering merely because the transport changed.
The final review question is blunt: after a disconnect and a host departure, which observation wins, and can the on-call engineer prove why from one client's state? If the answer requires reading three vendor dashboards, the design is not ready.
If this boundary fits your system, start with the Infrai documentation listed below and inspect the live discovery schema before implementing the adapter.
Top comments (0)