magnusberg2958

Posted on Sep 30

Node.js Watch Party Synchronisation 2026: Authoritative Host or Peer Consensus

#realtime #node #sre

A page fires: workspace_presence_mismatch has exceeded the error budget for 10 minutes. The on-call opens a logistics watch room used to review a delayed shipment, sees eight people marked online, and finds two playback positions on screen. The tempting diagnosis is a flaky socket. The more useful diagnosis is that the system never made one participant authoritative.

TL;DR: use a single host as the source of truth for playback position in a Node.js watch party. Treat presence as evidence that the host may have left, then run an explicit, deterministic handoff. Do not ask every peer to agree on every play, pause, or seek unless surviving partitions without a central authority is a product requirement worth a much larger protocol and on-call budget. Perfect synchronization is impossible; expose a small tolerance in the interface instead of promising lockstep playback.

That answer optimizes for presence accuracy, not architectural novelty. In a shared logistics workspace, an incorrect "online" badge can select a departed dispatcher as leader, while a delayed departure signal can leave every viewer waiting. The earlier signal should therefore be leader liveness and playback divergence, not merely socket count.

What should have paged before viewers split?

The actionable signal is the fraction of active viewers whose reported media position differs from the authoritative position by more than the product's declared tolerance, segmented by room and leader epoch. Page on sustained user-visible divergence; ticket isolated corrections. A raw disconnect counter has no such meaning because mobile networks reconnect, browsers suspend tabs, and a transport connection is not the same thing as an active person.

Capacity planning starts with event shape. For R rooms, V viewers per room, and one progress report every I seconds, inbound report rate is approximately R * V / I. At 2,000 rooms, 12 viewers per room, and a five-second interval, that is 4,800 reports per second before reconnect bursts. Those numbers are an example workload for sizing, not a benchmark or a claim about any vendor. They force the useful questions: Can the gateway absorb a synchronized reconnect wave? How old may a presence record become before it is excluded from leadership? How much write amplification does the observability pipeline tolerate?

Instrument four values together: room_id, leader_epoch, authoritative_position_ms, and observed_position_ms. Also record the age of the presence observation used for any election. An alert that cannot distinguish stale membership from playback drift sends the on-call toward the wrong subsystem.

Short pages win. So do boring protocols.

Should watch party playback use an authoritative host or peer consensus?

With one authoritative host, every command has an obvious order. The host publishes an event containing a monotonically increasing sequence number, its current leader epoch, the media position, and whether playback is running. Viewers ignore events from an older epoch or with a lower sequence number. They adjust when drift exceeds the UI's stated tolerance; they do not continuously chase millisecond differences caused by network and scheduler jitter.

The failure is equally obvious: the host can leave. Handle it as a state transition. Freeze new playback commands, confirm that the leader is absent according to the configured presence policy, select a successor by a stable rule such as the earliest eligible join in the current membership view, increment the epoch through the server-side coordinator, and resume from the last accepted authoritative state. The coordinator must serialize this transition. If two candidates can independently mint the same new epoch, the design has quietly recreated consensus without admitting it.

This is why presence accuracy belongs in the control plane but should not become the control plane. An online list answers "who appears available now?" It does not prove that all peers saw the same membership in the same order. During reconnects, two clients may briefly hold different but reasonable views. Let a server validate the handoff.

Peer consensus changes the contract. Peers need membership epochs, quorum rules, command ordering, duplicate suppression, partition behavior, and a recovery path for a member that missed decisions. A naive majority vote also behaves poorly in a two-person room: one departure eliminates the majority. Mature consensus algorithms address such cases, but implementing one inside a watch feature is a substantial distributed-systems commitment. Choose it only when a central coordinator is unacceptable and room continuity across coordinator loss is an explicit SLO.

The trade is blunt.

The instrumentation change

The page becomes diagnosable when presence, authority, and playback are correlated rather than counted in separate dashboards. A room-level trace should read like a timeline: leader heartbeat observed, departure threshold crossed, command intake paused, successor committed, new epoch published, viewers converged. The SLO should measure what a viewer experiences, while the supporting metrics explain why it happened.

For the logistics workspace, I would define availability as the proportion of room-minutes in which an eligible online participant can issue a command that becomes authoritative within the product's target window. A second indicator measures accurate presence: the proportion of sampled membership states that match the server's eligibility rules. The exact target and tolerance are product decisions; no universal number can be inferred from the transport.

The following Go probe shows the narrow integration boundary for reading presence through a plain REST API. It uses no vendor SDK, always sends an explicit method, checks response status, and honors Retry-After on rate limiting. That plain HTTP surface is the relevant advantage of Infrai here: a Node.js service, a Go diagnostic, or another runtime can use the same contract without adopting a client library. Keep the API call at the edge; leader epochs and election policy remain application logic. The base URL comes from deployment configuration because this independent comparison intentionally doesn't embed a vendor link; set it to the service's documented v1 API base.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

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

    baseURL := os.Getenv("REALTIME_API_BASE_URL")
    if baseURL == "" {
        panic("REALTIME_API_BASE_URL is required")
    }
    url := baseURL + "/realtime/presence/get/logistics-watch-room"
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodGet, url, nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)

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

        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("presence request failed: status=%d body=%s", resp.StatusCode, body))
        }

        fmt.Println(string(body))
        return
    }
    panic("presence request remained rate limited after retries")
}

The probe deliberately prints the verified response rather than pretending to know undeclared member fields. Production code should decode the published schema, attach the trace identifiers used by the coordinator, and bound total retry time to the caller's deadline.

Buy, build, or accept a different abstraction

The vendor decision is separate from the authority decision. Ably, Pusher Channels, PubNub, and Liveblocks all provide managed realtime building blocks, but their public product models emphasize different primitives. None removes the need to define who may lead, how departure is confirmed, and what happens during an ambiguous reconnect.

Option	Relevant documented primitive	Operational trade-off for this design
Ably	Presence membership and enter, update, and leave events	A broad managed realtime platform reduces transport ownership; application code still owns leader epochs and the meaning of stale presence.
Pusher Channels	Presence channels expose subscribed members and membership events	The channel model is direct for online indicators; leadership and playback ordering remain above it.
PubNub	Presence provides occupancy and join, leave, timeout, and state events	Rich presence events help observe membership changes; more event types also require a deliberate eligibility policy.
Liveblocks	Presence is ephemeral room state synchronized among connected clients	A collaborative-room abstraction fits shared UI state; evaluate whether its room model matches a server-authoritative playback coordinator.
Infrai	Realtime presence and publish capabilities behind one REST API	No SDK or client-library version is required, and the same key spans the broader API; the application must still implement authority and handoff policy.
Self-hosted Node.js gateway	Complete control over sockets, membership storage, and election logic	Maximum control and portability, paired with full responsibility for capacity, reconnect storms, regional failure, observability, and on-call response.

This table is not a feature-equivalence claim. Run a failure-oriented evaluation against current documentation: suspend the leader's browser, sever its network without a clean close, reconnect it after a successor exists, and deliver old commands late. Record when each system reports departure and what guarantees its transport provides. Product fit lives in those semantics, not in a checklist that says "presence: yes."

Managed service versus self-hosting is mostly an ownership decision. Buy when transport operations are undifferentiated work and the provider's presence semantics fit the SLO. Build when protocol control, deployment constraints, or lock-in costs justify carrying 24/7 operational responsibility. For a modest watch-party feature, I would spend engineering effort on deterministic recovery and honest UX before building a realtime control plane.

My decision rule is narrower: if the team can't state the partition behavior on one page, it shouldn't ship peer consensus. A managed transport can reduce pager surface, but it cannot choose the product's authority semantics; self-hosting can remove a vendor dependency, but it adds a system whose reconnect behavior, saturation point, regional topology, deploy safety, and incident ownership all need named owners. I would revisit that choice only after the requirements demand decentralized survival, not because consensus looks more elegant on a whiteboard.

Failure policy is part of the interface

The UI should distinguish "online," "reconnecting," and "host unavailable" when the underlying state supports those conclusions. During election, disable or queue control gestures visibly. After a new leader is committed, viewers may need a bounded seek to converge. Say that playback is synchronizing. Don't claim perfect synchronization, because propagation delay, media buffering, clock skew, and browser scheduling make it unattainable.

Users will notice anyway.

The false-positive cost sets the departure threshold. Too short, and a transient network pause removes a healthy host, increments the epoch, and forces disruptive reseeks. Too long, and the room remains leaderless while people wait. A logistics review with active dispatchers may prefer a faster visible handoff; a passive training replay may tolerate a longer grace period. Use observed reconnect and correction distributions from your own service to set the threshold, then revisit it through the error budget. There is no credible universal constant.

That returns us to the original page. If it fires on divergence tied to leader epoch and presence age, the on-call can decide whether the system is failing its viewer-facing objective. If it fires on socket churn alone, it measures activity while hiding the decision that matters.

DEV Community