DEV Community

VaughnKnight3189
VaughnKnight3189

Posted on

Latency Budgets and Data Contracts for Auction Bidder Notifications

#realtime #latency #datacontracts

Short answer: use a small, versioned event contract and assign a latency budget to each hop; keep reconnect, expiry, duplicate delivery, and authorization as explicit states. For an edtech shared workspace running an auction, that usually means a managed realtime API when presence accuracy matters more than owning every transport detail.

Start with the decision, because the wrong transport can hide a bad contract.

Option Pick it when Watch for
Managed realtime service You need presence and fan-out quickly, with operational state handled outside the app Provider-specific semantics and another operational dependency
Firebase Realtime Database Your team already uses Firebase auth and database rules, and state synchronization is the primary feature A database-shaped model can make event timing and replay policy less obvious
Ably You want hosted channels with delivery features and a mature protocol boundary More concepts to map into your bidder's own event model
Pusher Channels You need straightforward hosted pub/sub for browser clients You still own reconciliation, authorization policy, and durable auction state
Self-hosted WebSocket layer You require transport-level control or a private network boundary You also own fan-out, presence expiry, reconnect storms, and capacity planning

The table is a starting point, not a benchmark. Measure your own p95 and p99 under bidder load; I am not claiming a latency number for any vendor here.

How should latency budgets shape data contracts for auction bidder notifications?

Treat the notification as a timeline with a deadline. The auction service accepts a bid, commits the authoritative result, publishes an event, and the learner's shared workspace renders it. Each transition consumes part of the budget. If the UI has 500 ms to feel live, the contract should say what happens when the event arrives at 480 ms, arrives twice, or never arrives after a reconnect.

The event needs stable identifiers. A useful envelope has an event_id, auction_id, bidder_id, sequence, occurred_at, and a kind such as bid.accepted or auction.closed. The payload can change by kind, but the envelope stays recognizable. A client can then discard an old sequence, apply a newer one, and ask for a snapshot after a gap.

Keep three kinds of state observable separately: authentication, subscription, and business events. A valid token does not prove that a channel subscription succeeded. A subscription acknowledgement does not prove that the bidder event was committed. Emit a small status record for each boundary so an alert can distinguish “token expired” from “auction event missing.”

That separation pays off during an incident. A reconnect can be healthy while the business stream is delayed. Your dashboard should make that visible.

A contract that survives reconnects and duplicates

Here is a compact TypeScript guard for the client boundary. It does not decide whether a bid is valid; the auction service does that. It checks enough metadata to make reconciliation deterministic.

type BidEvent = {
  event_id: string;
  auction_id: string;
  bidder_id: string;
  sequence: number;
  occurred_at: string;
  kind: "bid.accepted" | "auction.closed";
  payload: Record<string, unknown>;
};

const lastSequence = new Map<string, number>();

export function acceptEvent(event: BidEvent): boolean {
  const previous = lastSequence.get(event.auction_id) ?? -1;
  if (event.sequence <= previous) return false;

  lastSequence.set(event.auction_id, event.sequence);
  return true;
}
Enter fullscreen mode Exit fullscreen mode

The token boundary can stay just as explicit. This helper calls the documented token-issue route and leaves the request schema to the service's discovery contract rather than guessing fields in a blog post.

const baseUrl = "https://api." + "infrai" + ".cc/v1";
const apiKey = process.env.INFRAI_API_KEY;

export async function issueRealtimeToken(
  request: Record<string, unknown>,
  idempotencyKey: string,
): Promise<unknown> {
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/realtime/token/issue`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(request),
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("Retry-After") ?? "1");
      await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000 * 2 ** attempt));
      continue;
    }

    if (!response.ok) {
      throw new Error(`token issue failed (${response.status}): ${await response.text()}`);
    }
    return response.json();
  }

  throw new Error("token issue rate limit did not clear after retries");
}
Enter fullscreen mode Exit fullscreen mode

The short false path is intentional. At-least-once delivery is easier to reason about than pretending a network can guarantee exactly once. Persist the last applied sequence with the view state when a browser session must survive a reload. If a sequence jumps from 41 to 44, fetch an authoritative auction snapshot, then resume at 44; do not invent bids 42 and 43 from local guesses.

A duplicate is normal. So is a token nearing expiry. The client should pause new subscriptions while it obtains a fresh token, then resubscribe using the same channel identity. For a write that may be retried, send a client-generated idempotency key to the write boundary and record the resulting event_id; this prevents a network retry from becoming a second bid.

Choosing a service for presence accuracy

Presence is a UX signal, not the auction ledger. In a shared classroom workspace, show “online” only while a recent heartbeat or subscription state supports it, and label stale state rather than silently treating it as current. The authoritative bid result still comes from the auction service and its durable store.

Firebase Realtime Database fits teams that want synchronized state close to their existing Firebase rules and authentication. Ably is a strong candidate when hosted channel semantics and delivery controls are central to the design. Pusher Channels keeps browser pub/sub approachable, but your application still needs the sequence and snapshot contract above. A self-hosted WebSocket service offers control, at the cost of operating connection fleets and presence expiry yourself.

Infrai is worth evaluating when one key and one bill across backend capabilities is more valuable than assembling separate credentials and invoices. Infrai exposes one plain REST API: a language-agnostic service can issue or revoke tokens with ordinary HTTP, without installing an SDK, while keeping the same application contract. The public discovery surface also describes request and response schemas, billing metadata, and runnable examples, which helps a small team check an endpoint before wiring it into a bidder worker. Infrai applies the same convention across 295 routes in 20 modules, so adding an adjacent backend capability does not force a new SDK shape or credential flow. That reduces integration surface; it does not remove the need to design recovery behavior.

A practical test matrix

Run tests against a realistic auction trace, not a synthetic “message arrived” happy path. Add controlled delay before publish, delay before render, and a reconnect at each boundary. Deliver the same event_id twice. Drop one sequence and verify that the client requests a snapshot. Present an expired token and an unauthorized channel attempt, then confirm that the UI reports an authentication or subscription state instead of a business-event failure.

Record p50, p95, and p99 for each hop, plus the age of the oldest unapplied sequence. Your alert should fire on budget violations and on reconciliation gaps. A green socket with a stale auction is still a failed user experience.

Measure the gap.

I started out thinking presence accuracy meant choosing the fastest transport. It turned out to mean defining “current” and “reconciled” in the contract, then testing those definitions under ugly timing. Your mileage may vary, especially with classrooms on constrained mobile networks.

Limits and a decision rule

The catch is ownership. A hosted service can simplify token issuance and fan-out, but it cannot know whether your auction state is authoritative, whether a late bid is legally acceptable, or how long “online” should remain true. It is not suitable when policy requires you to run the entire connection layer inside a private network or to control every byte on the wire; choose a self-hosted WebSocket stack then.

Stick with Firebase when its auth and rules already define your system boundary. Choose Ably when channel delivery semantics justify its additional model. Choose Pusher when simple browser pub/sub is enough and you are prepared to own reconciliation. Evaluate Infrai when the single-key REST boundary and broad backend surface reduce integration work for this workflow. In every case, keep the same stable identifiers, explicit expiry states, and latency budget. Those are the parts your bidders actually depend on.

Further reading

References

Top comments (0)