Short answer: treat room pagination as a reconnect protocol, not a scrolling feature. Keep a durable cursor per workspace, fetch a bounded page after reconnect, then apply events in order with an idempotent reducer. That is the least complicated way to show who is online in a shared fintech auction workspace without turning a brief network gap into a false presence state.
The data flow behind a trustworthy presence list
The dashboard has two inputs: a snapshot of room members and a stream of membership events. A room is the logical channel for one auction workspace. Pagination is the snapshot's continuation token, while the event stream carries changes that happen after that snapshot. Those two clocks must meet at a known point.
On first load, request page one and retain its cursor. Persist the last event sequence that the reducer has applied. On reconnect, ask for the next snapshot page or a backfill range, apply it, and only then resume live delivery. If the service gives you a cursor that has expired, restart from a fresh snapshot and mark the UI as synchronizing rather than silently showing stale traders.
This distinction matters in a live auction. A bidder can join while page two is loading, leave before page three arrives, and rejoin before the socket is healthy. Sorting the final names alphabetically cannot repair that history; ordering and deduplication can. I initially treated pagination as a rendering concern. I was wrong.
The cursor is state.
Order wins.
How should room pagination and reconnect work in a live auction dashboard?
I model the client as a tiny event-sourced system. The state is a map keyed by member ID, and the cursor is part of the state, not a component detail. Every event has a sequence, so an event with a sequence already applied is a no-op. A gap pauses normal rendering and triggers backfill.
Here is a generic Python sketch. The endpoint names are placeholders because the wire contract differs between systems; the important parts are the cursor boundary, bounded pages, and idempotent application.
from dataclasses import dataclass
from typing import Any, Callable
@dataclass
class RoomState:
members: dict[str, dict[str, Any]]
last_sequence: int = 0
next_cursor: str | None = None
syncing: bool = False
def apply_event(state: RoomState, event: dict[str, Any]) -> None:
sequence = int(event["sequence"])
if sequence <= state.last_sequence:
return
if sequence != state.last_sequence + 1:
state.syncing = True
raise ValueError(f"event gap: expected {state.last_sequence + 1}, got {sequence}")
member_id = event["member_id"]
if event["type"] in {"member_joined", "member_updated"}:
state.members[member_id] = event["member"]
elif event["type"] == "member_left":
state.members.pop(member_id, None)
state.last_sequence = sequence
def load_snapshot(
fetch_page: Callable[[str | None], dict[str, Any]],
state: RoomState,
) -> None:
cursor = state.next_cursor
while True:
page = fetch_page(cursor)
for member in page["members"]:
state.members[member["id"]] = member
cursor = page.get("next_cursor")
state.next_cursor = cursor
if cursor is None:
break
state.syncing = False
In production, fetch_page should carry a workspace or room identifier, a stable page size, and the cursor returned by the previous response. Do not use the visible member count as a cursor. Counts change during an auction and make page boundaries move underneath you.
The reducer also needs a policy for snapshot/event overlap. Prefer a snapshot watermark, such as snapshot_sequence, and discard stream events at or below that number. Without a watermark, a member can be inserted from the snapshot and then inserted again from the stream, which looks harmless until a leave event races the duplicate join.
Failure modes that make pagination look random
The most common failure is a cursor scoped to a page number instead of a server position. Page three may contain records that were on page two after a high-traffic burst. Cursor-based pagination avoids that shift, but only if the cursor is opaque and treated as a server token.
Another trap is applying pages directly to the rendered list while the socket keeps mutating the same list. That creates flicker and can resurrect a member who already left. Buffer incoming events during snapshot assembly, then replay only events newer than the snapshot watermark.
A reconnect timer is not a consistency strategy. Backoff helps protect the service, but it does not tell you whether you missed events. Track the last sequence, detect gaps, and expose a small “syncing” state in the dashboard. Traders need an honest status more than a green dot that is five minutes old.
Make the stale state visible.
I also test the ugly timeline explicitly: page one succeeds, the connection drops, page two returns, then an old leave event arrives. The useful test is longer than it sounds: seed the room with a member on page one, advance the server sequence, deliver a join while the client is offline, return a second page that includes the new member, replay the join twice, and finally deliver the old leave. The expected final state comes from an ordered event log, not from screenshots, and the assertion checks both the member map and the last sequence. That keeps a UI refactor from hiding a replay bug.
Choosing boundaries, limits, and observability
Set a maximum page size that keeps snapshot latency predictable. Large pages reduce round trips but increase the interval in which live events wait in the buffer. Small pages reduce that interval but amplify cursor expiry and request overhead. Your auction volume and reconnect distribution should decide the value; I am not sure one universal number exists.
Record cursor age, pages per resync, event-gap count, replay duration, and the age of the oldest displayed presence record. These measurements explain whether a “slow room” is a transport problem, a hot workspace, or a reducer that is doing too much work. Keep member payloads narrow; every extra field increases bandwidth and prompt or storage cost when the same state is fed into an agent.
The browser transport still needs a standards-based liveness signal. WebRTC applications, for example, define connection state transitions that can inform when a peer is disconnected, but your room service remains responsible for authoritative membership and replay. A transport saying “connected” is not proof that your cursor is current.
The catch is that this design is not suitable when you only need an approximate, ephemeral “someone is typing” indicator. A short-lived signal with a TTL is cheaper to reason about. Stick with a simple snapshot when the room is tiny, reconnects are rare, and losing a few seconds of presence has no financial consequence.
Before shipping, verify that cursors are opaque and durable for the documented retention window, that a snapshot has a sequence watermark, and that retries reuse the same cursor safely. Inject drops between every page, duplicate every event, and delay leaves longer than joins. Confirm the UI labels synchronization and clears that label only after the reducer catches up.
Run the same scenarios in a notebook and in the deployed client. Compare the resulting member map and last sequence, not DOM order. Finally, alert on unexplained cursor resets and sustained replay lag; those are early warnings that the room's pagination contract or retention policy no longer matches auction traffic. It's a small checklist, but it catches the expensive class of presence errors.
Further reading (References)
- W3C, “WebRTC Recommendation”: https://www.w3.org/TR/webrtc/
- MDN, “WebSocket API”: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
- RFC 9110, “HTTP Semantics” (status and caching semantics): https://www.rfc-editor.org/rfc/rfc9110
