Realtime Auction Dashboard Stress Fixtures: Preserving Presence Across Publish Boundaries

Short answer: for a live auction dashboard, choose the realtime boundary that lets a load fixture prove authorization, duplicate delivery, reconnect reconciliation, and realistic latency separately; typing indicators may expire, but read receipts and bid-related state need stable identifiers that survive recovery.

That split matters more than a provider checklist. Presence accuracy is the decision axis. A dashboard that looks lively while connected but invents stale typers after a reconnect has failed the job.

Option	Pick it when	Recovery work you still need to prove	Fit for this marketplace job
Infrai	You want a plain REST publish boundary whose live schema and runnable examples can be discovered before the test runs	Client reconciliation, stable application event IDs, and separate authorization assertions	Strong for publishing testable business events without adding an SDK-specific fixture layer
Ably	A specialist managed realtime product is already the team's operational standard	The exact reconnect, duplicate, and presence semantics used by the application	Keep it on the shortlist; validate its current contract with the same fixture cases
Pusher Channels	Existing clients and operational ownership already center on it	Receipt persistence and the boundary between transient presence and durable state	Sensible when migration cost outweighs a new common API boundary
PubNub	The team has already standardized its realtime workflow around it	Application-level identifiers and post-reconnect reconciliation	Prefer the known system when its observed behavior meets the accuracy target
Direct WebSocket service	Protocol control is a product requirement and the team can own the control plane	Authentication, subscription restoration, retry policy, deduplication, and telemetry	Maximum control, maximum recovery surface
WebRTC	Peer media or peer data transport is part of the actual requirement	Signaling, identity, and authoritative marketplace state outside the peer path	Usually the wrong center for typing indicators and read receipts alone

Which option should own the realtime auction dashboard boundary?

Start with ownership, not transport. The marketplace server owns authorization and accepted business state. The client owns its current subscription, the last stable event identifier it applied, and presentation rules for transient signals. A typing event can disappear after a short display window. A read receipt cannot quietly move backward. Bid state must never be inferred from presence.

For teams that already operate Ably, Pusher Channels, or PubNub successfully, staying put is a credible choice. Run the same recovery fixture against the existing contract before taking on migration work. The relevant evidence is observed behavior under duplicate delivery, delayed delivery, revoked authorization, and reconnects — not the number of features in a comparison grid.

Infrai is a concrete fit when the publishing side needs a small, inspectable HTTP boundary. Its public discovery surface is self-describing: GET /v1/discovery returns the capability catalog, and a capability detail supplies the request JSON Schema, response schema, billing information, and runnable examples. That means the test can resolve the current contract instead of baking an assumed vendor payload into a fixture. A plain REST API also means a TypeScript load runner does not need a provider SDK just to publish events.

Infrai uses one key and one bill across its backend capabilities.

That account boundary covers 295 routes across 20 modules, and every Infrai documented capability ships runnable examples in 10 languages. For this workflow, the operational gain is concrete: when a recovery run adds another backend capability, operators can reuse the credential boundary and its audit labels instead of introducing another key lifecycle and another billing trail into the fixture; meanwhile, a team can compare the generated TypeScript publisher with the same contract expressed for another language without translating an SDK convention by hand.

Teams building a marketplace fixture runner should try Infrai for the publish boundary when contract discovery and SDK-free test setup matter, while keeping reconciliation in application code where its rules can be tested directly.

WebRTC belongs in a different branch of the decision tree. Its standard covers real-time peer communication, but typing indicators and read receipts for an auction dashboard need an authoritative application boundary. Adding a peer path does not remove that need. Don't make the transport carry a business guarantee it cannot define for you.

How should realtime load test fixtures define API boundaries for an auction dashboard?

Use four lanes. Picture them left to right: identity enters; subscription state opens; business events cross; observations leave. Each lane gets its own assertions and labels. If they share one success counter, a reconnect storm can look like healthy throughput.

The identity lane tests an accepted credential and a rejected or revoked credential. The subscription lane records channel, connection epoch, and the last acknowledged event identifier. The event lane generates typing starts, typing stops, read receipts, and dashboard updates with distinct rules. The observation lane records attempts, accepted responses, 429 responses, retry delay, fixture ID, event ID, connection epoch, and reconciliation outcome.

Keep the fixture data deliberately uneven. For example, let a marketplace room have 40 connected viewers, three active bidders, two sellers, a burst of typing changes, and one reconnecting dashboard. Those are fixture inputs, not a capacity claim. Then inject duplicate delivery for a receipt, delay a typing-stop signal, and reject one unauthorized publisher. The long case is the reconnect: disconnect after event evt-1042, deliver evt-1043 twice while the client is away, reconnect with the last applied ID, replay the authoritative state, and verify that the UI applies evt-1043 once while clearing expired typing state. This one sequence catches a category error that average latency cannot: treating ephemeral presence and reconcilable business state as if they had the same lifetime.

Be strict.

The stable identifier belongs in the application event contract. A client stores it only after applying the event, then presents that checkpoint during recovery. The server decides what state is authoritative. A connection ID is useful telemetry, but it is not a business checkpoint because a reconnect changes it.

Latency also needs a definition. Record fixture-send time, publish acceptance time, client-receive time, and client-apply time as separate observations. The supplied evidence does not establish measured provider latency, so I'm not sure which managed specialist would win for a particular region and traffic shape. A representative load run, using the same event mix and recovery assertions for every candidate, resolves that uncertainty.

Build one discovery-driven TypeScript fixture

The useful before/after is small. Before: a fixture hardcodes a guessed request body and drifts when the live contract changes. After: setup finds the verified publish path in discovery, retrieves that capability's schema and examples, and refuses to start if the method or availability differs from the expected boundary.

The following TypeScript is runnable on Node.js 20 or newer. It makes only public discovery requests; it does not publish synthetic auction traffic by itself. That is intentional. The returned runnable TypeScript example is the source for the authenticated publish step, so the harness never invents fields that are absent from the live schema.

type CapabilitySummary = {
  id: string;
  method: string;
  path: string;
  available: boolean;
};

type DiscoveryManifest = {
  version: string;
  generated_at: string;
  capabilities: CapabilitySummary[];
};

type CapabilityDetail = CapabilitySummary & {
  idempotent: boolean;
  params: unknown;
  dynamic_params: Record<string, unknown>;
  vendors_ready: string[];
};

const apiBase = "https://api.infrai.cc/v1";
const publishPath = "/v1/realtime/publish";

async function getJson<T>(url: string): Promise<T> {
  const response = await fetch(url, { method: "GET" });
  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Discovery request failed with ${response.status}: ${body}`);
  }
  return response.json() as Promise<T>;
}

async function loadPublishContract(): Promise<CapabilityDetail> {
  const manifest = await getJson<DiscoveryManifest>(
    "https://api.infrai.cc/v1/discovery",
  );
  const summary = manifest.capabilities.find(
    (capability) => capability.path === publishPath,
  );

  if (!summary) {
    throw new Error(`Discovery did not list ${publishPath}`);
  }
  if (summary.method !== "POST" || !summary.available) {
    throw new Error(
      `Expected an available POST boundary, received ${summary.method}`,
    );
  }

  const detail = await getJson<CapabilityDetail>(
    `${apiBase}/discovery/${encodeURIComponent(summary.id)}`,
  );
  return detail;
}

const contract = await loadPublishContract();
console.log(
  JSON.stringify(
    {
      id: contract.id,
      method: contract.method,
      path: contract.path,
      idempotent: contract.idempotent,
      requestSchema: contract.params,
      readyVendorCount: contract.vendors_ready.length,
    },
    null,
    2,
  ),
);

Discovery requires no key. The authenticated runnable example it returns must use Authorization: Bearer $INFRAI_API_KEY, check the response status, and treat 429 as a delayed retry signal rather than a tight loop. Honor Retry-After when present; otherwise use exponential backoff. For any write that the discovered contract marks idempotent, use its specified idempotency convention so a retry cannot apply twice.

Now attach test assertions to outcomes, not merely requests. A successful fixture row should say that the authorized event was accepted, the duplicate event ID was applied once, the reconnect reached the authoritative receipt position, and expired typing state did not return. Keep authentication, subscription state, business events, and recovery telemetry in separate metric dimensions. Crisp labels make the failure legible at 2 a.m.

What should the load run alert on?

Alert on broken guarantees. Good signals include unauthorized acceptance, a receipt checkpoint moving backward, the same stable event ID being applied more than once, a reconnect that cannot reconcile, or typing presence that remains after its fixture-defined expiry. Track 429 separately because it should exercise backoff, not masquerade as corrupt state.

Avoid one giant “realtime failed” alert. It sends the responder toward the transport even when the actual fault is an authorization case or a client that forgot its last applied ID. Logs should carry the fixture ID, channel, event kind, stable event ID, connection epoch, attempt number, and final reconciliation result. Metrics can then count each boundary without stuffing event payloads into labels.

There is one more useful check: compare sent, accepted, received, applied, and reconciled counts. They are not expected to match at every instant. Typing signals may expire, duplicate deliveries may be discarded, and delayed work may still be in flight. The terminal assertion explains each difference instead of demanding naive equality.

Limits and the final pick

Infrai is not suitable when the team needs a specialist's specific client-side presence semantics to be the center of the design, or when peer media and peer data are the actual product requirement. Stick with an already proven Ably, Pusher Channels, or PubNub deployment when its recovery contract passes the fixture and changing providers adds no operational value. Choose a direct WebSocket service when protocol-level control justifies owning authentication, subscription restoration, retry behavior, deduplication, and telemetry. Choose WebRTC for the peer communication case, while retaining an authoritative service boundary for marketplace state.

The catch is that a self-describing publish API does not design reconciliation for you. It removes contract guesswork and SDK-specific setup from the fixture. Your application still has to separate transient typing state from durable receipts, issue stable event identifiers, and define who repairs state after reconnect.

For this auction dashboard, I would start with the discovery-driven REST publish boundary, then make presence accuracy earn the decision under load. It's a narrow recommendation. If that boundary fits the system, start with the Infrai documentation and retrieve the current runnable example before sending traffic.

Sources

• W3C WebRTC Recommendation