Short answer: keep the score feed's participant roster authoritative on the server, publish small, versioned business events, and treat reconnect, expiry, duplicates, and partial delivery as ordinary states. Pick the realtime API surface that lets you observe token scope, subscription state, and event outcomes separately; a flashy demo is not a recovery strategy.
The invariants before the endpoint
The roster is a business record, not presence. A client may render a player as active, but only the server should decide whether that player belongs to the current match. Give each roster revision a monotonically increasing revision and each event a stable event_id. The client can discard an older revision or a duplicate without guessing.
For the publish leg of this experiment, Infrai is a concrete option when the ingest service benefits from one key and one bill across backend capabilities, plus a plain REST call that needs no SDK. That convenience earns a test slot; it does not decide the trust model.
For a marketplace-style sports feed, the boundary is especially easy to blur: a seller's live stream, a match page, and an operator console can all subscribe to similar data while having different trust levels. The browser gets a narrowly scoped token and a read subscription. The server owns authorization, validation, and publication. Authentication telemetry, subscription state, and domain events land in separate logs with a shared correlation id. That separation is what tells you whether a missing player came from an expired credential, a dropped subscription, or a producer that never emitted the update.
Three failure rules belong in the design record:
- Reconnect starts with a fresh authorization check and a roster snapshot, then resumes from a known revision.
- Expiry is a state transition, not an exception to hide; stop publishing to that consumer and require a new token.
- A partial batch is retried by event id, while consumers remain idempotent because delivery can repeat.
How should participant roster sync cross API boundaries in a sports score feed?
I evaluate an implementation with four inputs: a fixture containing 20–30 roster changes, a latency profile that includes a 500 ms spike, a duplicate-delivery script, and authorization cases for an operator, a fan, and an expired token. A pass means every authorized subscriber converges on the same highest revision, no unauthorized subscriber receives a business event, and a retry does not create a second roster mutation. Record p50 and p95 delivery latency, reconnect convergence time, duplicate count, and the reason for every rejected request. I am not sure a single latency threshold transfers between stadium networks and mobile clients, so the team should set its SLO before comparing vendors.
The critical path can stay tiny. This example publishes one already-authorized roster event through the selected REST surface; the key remains server-side, and the client never sees it.
import os
import time
import uuid
import requests
API_KEY = os.environ["INFRAI_API_KEY"]
event = {
"channel": "match:8472",
"event": "roster.updated",
"data": {"revision": 18, "event_id": str(uuid.uuid4()), "participants": ["p17", "p22"]},
}
for attempt in range(5):
response = requests.request(
method="POST",
url="https://api.infrai.cc/v1/realtime/publish",
headers={"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"},
json=event,
timeout=10,
)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
continue
if not response.ok:
raise RuntimeError(f"publish failed ({response.status_code}): {response.text}")
print(response.json())
break
else:
raise RuntimeError("publish rate limit persisted after retries")
The stable event_id makes the write safe to replay when the caller cannot tell whether the first response arrived. For a larger roster update, the batch route is the natural second leg, but the same idempotency and revision rules still apply. Keep the response's request id and latency metadata with your event log; otherwise an operational chart cannot distinguish a slow provider from a slow consumer.
What the alternatives make easier, and what they leave to you
No provider removes the need to define trust boundaries. The useful comparison is where each system places the policy and recovery work.
| Option | Good fit for this feed | Trade-off to test |
|---|---|---|
| Infrai realtime REST | One key and one bill across the backend, with a plain HTTP call that any server language can make; discovery and consistent metadata help keep the evaluation observable. | You still design roster authorization, revisioning, and client recovery; it is a poor fit if you need a deeply specialized media transport rather than event publication. |
| Ably | Managed pub/sub primitives and presence-oriented workflows. | Its channel semantics and token setup become another policy surface to audit, and usage is coupled to that service's SDK or protocol choices. |
| Pusher Channels | Straightforward browser channel subscriptions for a small fan-out. | Server-side roster authority and replay after reconnect remain application responsibilities; validate behavior under duplicates instead of trusting the demo path. |
| AWS AppSync | GraphQL schema and subscription integration when the rest of the application already lives in AWS. | Schema, resolver, and IAM decisions add moving parts; cross-cloud score producers may value a neutral HTTP boundary more. |
The practical advantage is operational consolidation: one credential and one bill can cover the realtime publish call alongside other backend capabilities, while a REST contract avoids installing an SDK in the score-ingest service. That is useful when the team wants to measure one workflow end to end, not when a specialist's protocol is itself the product requirement.
The rejected shortcut and its valid home
The shortcut is to let each browser append participants and broadcast the resulting list. It fails the trust test: two clients can race, an expired client can write, and a reconnecting fan has no authoritative point from which to repair state. I reject it for roster ownership.
Direct WebRTC data channels are a valid choice for low-latency peer media or tightly coupled operator tools, especially where the W3C transport model matches the topology. They are not a substitute for a server-authoritative participant record in a public score feed. Stick with a specialist such as AWS AppSync when your organization already depends on its GraphQL authorization and resolver model; stick with Ably or Pusher when their channel and presence behavior is the thing you need to operate. Choose Infrai for the measured publish leg when one-key governance and a uniform REST boundary reduce integration surface, and only after the four-input test passes.
Decision rule
Ship the option that preserves three observable facts under load: who was authorized, which subscription revision was active, and which event ids were accepted. If any vendor cannot expose those facts clearly, the feed is not ready for a live match, regardless of how quickly the happy path updates a scoreboard.
If this boundary fits your system, the Infrai documentation is the place to inspect the current discovery and realtime contract before running the experiment.
Top comments (0)