DEV Community

MaximilianNilsson7568
MaximilianNilsson7568

Posted on

Realtime Optimistic Updates and WebRTC Reconciliation for Consultation Session Failures

#webrtc #realtime #architecture

Short answer: a video consultation room should apply optimistic updates only to reversible interface state, tag every mutation with a scoped session token and idempotency key, and reconcile against an authoritative room log after any disconnect. WebRTC can carry low-latency presence and cursor traffic, but it should not turn an unconfirmed clinical action into a fact. The uncomfortable trade-off is deliberate: cursors may briefly jump after reconnection; consent, appointment status, and clinician notes must never be guessed.

This is a trust-boundary problem disguised as a latency problem. A patient can reasonably trust the local mute icon to react at once. They cannot reasonably be told that consent was recorded merely because one browser changed color. The architecture has to distinguish those two promises before anyone chooses a transport.

How should a video consultation room handle realtime optimistic update failures?

Start by dividing room state into three classes. Ephemeral state includes pointer position, typing indicators, raised-hand animations, and the selection range in a shared note editor. Session state includes participant presence, active speaker, device status, and the current presenter. Durable clinical state includes consent, finalized notes, prescriptions, recording authorization, and appointment disposition. Those classes can share a screen, but they should not share a confirmation rule.

An optimistic cursor update can render locally, receive a monotonically increasing client sequence number, and travel over an RTCDataChannel. On reconnect, the client discards cursor messages older than the latest accepted sequence for that participant. Losing one intermediate coordinate is harmless because a newer coordinate replaces it. A finalized note is different: it needs an idempotent command to an authoritative service, a durable acknowledgement, and a server-assigned revision that every client can reconcile. If the acknowledgement is missing, the interface must show pending or unknown rather than success.

Keep that distinction blunt.

The shared clinical-note editor makes the boundary visible. A cursor may be scoped to consultation_id, document_id, participant_id, and a short-lived connection epoch. The token presented to the realtime channel should authorize only the intended room and operations, not every consultation visible to the user. A cursor event should carry no clinical text; it needs a position, selection extent, actor pseudonym, sequence, and expiry. The document operation itself belongs to the editor's convergence protocol and durable audit path. Mixing cursor presence with document content creates a broader disclosure surface for no useful consistency gain.

The server also has to treat the client as untrusted. It validates room membership, token audience and expiry, operation type, payload bounds, and the relationship between the participant and document before relaying anything. A client timestamp can help with diagnostics, but it cannot establish order: clocks drift, tabs pause, and packets can arrive late. Server-observed epochs and per-sender sequence numbers make a safer ordering rule.

The acknowledgement boundary is the product contract

“Optimistic” is too broad unless the UI specifies what acknowledgement means. There are at least four useful states: locally applied, accepted for relay, committed by the authority, and observed in a fresh snapshot. A transport-level send only proves that the local stack accepted bytes. It does not prove that a peer rendered them, that a service persisted them, or that the actor still had permission when the operation reached the authority.

For ephemeral updates, accepted-for-relay may be enough. For durable clinical changes, only an authoritative commit should produce a success state. Reconciliation then compares a known server revision with the client's pending command set. The client resends commands by idempotency key, accepts one canonical result, and removes pending entries only when that result is represented in the authoritative snapshot or event stream.

This Python sketch models the client-side decision without coupling it to a particular transport:

from dataclasses import dataclass, field
from enum import Enum
from typing import Any


class Assurance(Enum):
    EPHEMERAL = "ephemeral"
    DURABLE = "durable"


@dataclass(frozen=True)
class Mutation:
    mutation_id: str
    room_id: str
    actor_id: str
    sequence: int
    assurance: Assurance
    payload: dict[str, Any]


@dataclass
class RoomState:
    server_revision: int = 0
    pending: dict[str, Mutation] = field(default_factory=dict)
    latest_cursor_sequence: dict[str, int] = field(default_factory=dict)

    def apply_local(self, mutation: Mutation) -> None:
        if mutation.assurance is Assurance.DURABLE:
            self.pending[mutation.mutation_id] = mutation
            return

        previous = self.latest_cursor_sequence.get(mutation.actor_id, -1)
        if mutation.sequence > previous:
            self.latest_cursor_sequence[mutation.actor_id] = mutation.sequence

    def reconcile(self, revision: int, committed_ids: set[str]) -> None:
        if revision < self.server_revision:
            return
        self.server_revision = revision
        for mutation_id in committed_ids:
            self.pending.pop(mutation_id, None)
Enter fullscreen mode Exit fullscreen mode

The code intentionally does not infer that a missing mutation failed. After a disconnect, absence is uncertainty. The durable command may have committed while its acknowledgement was lost, which is why retrying with the same idempotency key matters. Generating a new key on every retry can duplicate an action that was already accepted.

There is another catch: reconciliation cannot repair an authorization model that grants too much. A room token should be audience-bound, short-lived, and limited by action and resource. Refresh should happen through a trusted application channel, and revocation should prevent a reconnect from silently restoring capabilities that an administrator or clinician removed. Bearer tokens require careful handling because possession is sufficient for use; the OAuth bearer-token specification describes the threat model, while JWT best-current-practice guidance covers validation pitfalls such as algorithm confusion and incorrect audience processing.

Name failures before selecting the realtime path

The useful comparison is not “fastest protocol.” It is which failure semantics the room can tolerate.

Failure mode Visible symptom Required response Suitable path
Brief packet loss Cursor skips a position Replace with the newest sequence; do not replay stale motion Unreliable or time-bounded data channel
Reordered delivery Pointer moves backward Reject a sequence at or below the actor's accepted sequence Ordered channel, or application sequencing
Signaling interruption Peer connection cannot be restored immediately Mark presence uncertain and obtain a fresh room snapshot Reconnect plus authoritative sync
Lost acknowledgement Durable action remains pending Retry the same command key and fetch its canonical result Reliable application API
Permission change A formerly valid client attempts another action Reauthorize at the server and reject unauthorized relay Scoped token plus server enforcement
Duplicate browser tab Two connection epochs emit for one actor Fence the older epoch or represent both explicitly Server-issued connection epochs

WebRTC data channels expose ordered delivery and retransmission controls, so they fit high-rate state whose value decays quickly. WebSocket provides a reliable, ordered, full-duplex byte stream over a single connection and can be easier to operate when media is already handled elsewhere. Server-sent events are one-way from server to browser, which can suit authoritative notifications while client commands use regular HTTP. None of these choices supplies authorization, idempotency, durable history, or application-level conflict resolution. Those remain architecture work.

I'm not sure a single transport choice can be justified without the deployment's loss, reconnect, and mobile-backgrounding measurements. That uncertainty is resolvable: record connection-state transitions, reconnect duration, stale-event rejection, pending-command age, snapshot revision gaps, and authorization denials, while keeping clinical payloads out of telemetry. Compare distributions by network type and client version rather than relying on a clean office connection.

Do not log cursor coordinates with patient identity by default. Even apparently harmless presence telemetry can become sensitive when joined with consultation timing and document context. Prefer counters and bounded identifiers, define retention, and make access to detailed traces exceptional.

Where optimistic behavior is not suitable

Optimistic rendering is not suitable when a mistaken success state could change care, consent, access, billing, or the legal record. Keep those operations pending until the authority commits them. It is also a poor fit when conflicts cannot be undone cleanly, when the client cannot obtain a fresh snapshot, or when an offline actor might retain permissions after revocation.

The catch is that strict confirmation increases perceived latency. For a consent action, that is acceptable; show a clear pending state and disable dependent actions until confirmation. For a pointer moving across shared notes, the same rule would make collaboration feel broken, so allow immediate local motion and tolerate correction. This is not inconsistency by accident. It is a per-field consistency budget.

Stick with a conventional request-and-response API when update frequency is low and authoritative confirmation is the whole experience. Use a reliable bidirectional channel when ordered events dominate and the operating team wants one connection model. Use a WebRTC data channel when peer-oriented, latency-sensitive state belongs beside an existing WebRTC media session and the team is prepared to handle connection negotiation, channel state, and reconciliation. A hybrid is often coherent, but it costs more to test: ephemeral presence on the realtime path, durable commands on the authority path, and snapshots as the recovery bridge.

No protocol removes the need for load shedding. Cursor traffic should be coalesced because queued old coordinates have negative value, while durable commands must not be silently dropped. Backpressure policy therefore follows the same assurance classes as the UI. If one generic queue handles both, a cursor burst can delay the action that actually matters.

Roll out by proving recovery, not the happy path

Begin with a shadow reconciliation pass that compares client revision, authoritative revision, and pending command identifiers without changing the visible UI. Then enable optimistic rendering only for cursor and presence fields. Add durable actions one at a time after duplicate-command, lost-acknowledgement, expired-token, permission-revocation, and reconnect tests pass.

The minimum release suite should force reordered cursor messages, drop the final acknowledgement after a successful commit, open a second tab with an older connection epoch, expire the room token during a call, and restore a client from a stale snapshot. Assertions should cover both state and language: a pending action must never be labeled complete, and an unauthorized client must never receive another room's events.

Ship dashboards for pending age, reconciliation frequency, rejected stale sequences, reconnect outcomes, and authorization denials. Alert on sustained changes, not individual disconnects. Finally, rehearse disabling optimistic behavior by state class; a server-provided policy flag can move a risky field back to confirmed rendering without changing the storage contract.

The decision rule is compact: optimize what can be replaced, confirm what must be believed, and reconcile everything after trust or connectivity changes.

References

Top comments (0)