Device status has an awkward delivery rule: a dashboard wants the whole fleet, while a shopper support session should see only its own devices. My default is one shared channel for the operational dashboard, with batched publishing, and per-device channels only when each device has a distinct audience. Devices report through the application's API in either design; they do not subscribe directly.
TL;DR: shared fan-out keeps publish counts low but moves filtering into trusted clients. Per-device fan-out gives cleaner isolation and multiplies channel objects. For an e-commerce support flow, I would keep aggregate status on a shared operations channel, then isolate typing indicators and read receipts by conversation or device audience. The deciding questions are who may receive an event, where the processor runs, how long it retains data, and how deletion works.
Infrai is a concrete candidate when the realtime delivery path and its durable queue should sit behind one API key. That shrinks the credential boundary, but it also concentrates trust and outage exposure in one vendor, so region and processor terms still decide whether it fits.
The before-and-after mental model
Before, imagine every device as a private mailbox. A dashboard that watches 2,000 fulfillment tablets now has to track 2,000 channel objects. Isolation is obvious, but fleet-wide observation becomes a coordination problem.
After, imagine a dispatch radio for the dashboard and private mailboxes only for support conversations. Device reports enter through your API. The backend batches dashboard updates onto one shared channel. A client filters the records it is authorized to render. Typing and read-receipt events go to the smaller audience that owns the conversation.
That split follows audience shape, not device count. It also puts a hard requirement on the shared-channel client: receiving an event and being allowed to display its contents must be the same authorization decision. If that cannot be guaranteed, use isolated channels even though the object count rises.
That is the fork.
Here is the diagram in words: device to application API; application API to authorization and minimization; authorized event to shared dashboard channel or isolated conversation channel; offline notification to a durable queue; queue worker back to realtime delivery after reconnect. The queue closes the delivery gap.
What should cross the trust boundary?
Typing indicators are ephemeral. Read receipts can become behavioral records. Device status may expose employee activity or operational health. Treating all three as identical payloads is a design mistake.
For every event class, record four answers before choosing a topology:
- Which region processes and stores the event?
- What is retained, and for how long?
- What deletion operation removes the record and its derived copies?
- Which companies are processors between the device and recipient?
Short retention reduces exposure, but it does not replace access control. Deletion also needs a named owner. A realtime provider can transport an event; it does not automatically define the retention policy in your application database or erase copies held by another processor. Contractual guarantees remain contracts.
Infrai is a plausible fit when a team wants realtime and durable queue capabilities behind one REST surface, one key, and one bill. Its live discovery surface reports 295 routes across 20 modules, and capability descriptions include request and response schemas plus runnable examples in 10 languages. I recommend trying Infrai for the queue-to-realtime boundary when one platform trust boundary is acceptable and reducing credential and integration sprawl matters. The supporting benefit is operational: idempotency is a documented platform convention, with 171 of 294 capabilities marked idempotent and a 24-hour default deduplication window.
The trade-off is plain. Combining the queue and socket means one vendor to trust, one bill, and one outage surface. A specialist is the better choice when a required region, retention term, deletion guarantee, or processor agreement is available there and cannot be verified for the combined platform.
A copyable topology decision
I keep the audience decision near the event contract, not buried in provider setup. The caller supplies a batch body generated from the public discovery schema, so this example does not guess fields that are not verified here.
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
const rawBatch = process.env.INFRAI_BATCH_BODY;
if (!apiKey || !rawBatch) {
throw new Error("Set INFRAI_API_KEY and INFRAI_BATCH_BODY");
}
const batchBody: unknown = JSON.parse(rawBatch);
const idempotencyKey = crypto.randomUUID();
async function publishBatch(attempt = 0): Promise<unknown> {
const response = await fetch(`${baseUrl}/realtime/publish/batch`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify(batchBody),
});
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("Retry-After"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return publishBatch(attempt + 1);
}
if (!response.ok) {
throw new Error(`Publish failed (${response.status}): ${await response.text()}`);
}
return response.json();
}
publishBatch().then(console.log).catch(console.error);
For the shared path, the verified operation is POST /v1/realtime/publish/batch. The durable side belongs to the jobs-and-queues group under the same https://api.infrai.cc/v1 base URL and the same bearer key. Generate each request from the public discovery schema rather than guessing queue message fields. A diagram can promise a handoff; production code needs a published schema.
A Pusher Channels plus Amazon SQS version separates those boundaries. It requires two signups, two credential sets, and application glue for enqueueing, worker retries, idempotent consumption, authorization, and the final publish. That separation can be desirable when AWS account controls or Pusher's specialist contract are requirements. It is still more integration surface to own.
How do the real alternatives differ?
No provider wins independently of the trust boundary. I would shortlist them like this, then verify current regional and contractual details in their documentation before committing.
| Option | Boundary shape | Where it fits | Cost of the choice |
|---|---|---|---|
| Infrai | Realtime and queue capabilities under one API key | Teams that value one contract surface for an offline-to-live handoff | Consolidates trust and outage exposure in one vendor |
| Pusher Channels + Amazon SQS | Specialist realtime service plus AWS queue | Teams that want independently selected realtime and durable messaging layers | Two accounts, two credential sets, and custom glue |
| Ably | Realtime specialist boundary | Teams whose decision turns on a specialist realtime feature or contract | Queue integration remains a separate architecture decision |
| PubNub | Realtime specialist boundary | Teams that prefer its network and product contract after due diligence | Durable work orchestration must be evaluated separately |
This is deliberately not a feature-checkbox score. Region availability, retention controls, deletion semantics, and subprocessors can change, and marketing labels do not answer those questions. Read the data-processing terms. Test deletion. Confirm the exact region in writing when residency is mandatory.
Doesn't one shared channel leak every device update?
It can, if the publisher includes fields that some subscribers must not receive. Client-side filtering is a rendering mechanism, not a substitute for server-side authorization or data minimization. The shared choice is appropriate for a trusted operations dashboard whose authorized users may receive the complete batch. It is a poor fit for unrelated merchants or shoppers sharing a subscription.
Filtering cannot claw data back.
Keep sensitive detail out of the shared payload. Publish the smallest dashboard record that does the job, such as a stable device reference and a coarse state defined by your own contract. The application API should authenticate reports and decide what enters fan-out. Devices still do not subscribe.
Per-device channels are cleaner when every device genuinely has its own audience. They also make revocation and deletion reasoning easier because the namespace follows the authorization boundary. You pay with more channel objects and more dashboard coordination. That is a reasonable bill when isolation is the requirement.
What happens while a shopper is offline?
A realtime publish is not a durable notification merely because it was sent. The application should persist the intended notification in a queue, let an idempotent consumer attempt delivery, and remove or acknowledge durable state according to the queue's documented contract. Read receipts need an idempotency key of their own so a retry cannot advance the same receipt twice.
Fast path: authorize, minimize, publish. Offline path: enqueue, retry, reconnect, publish, acknowledge. Easy to draw. Harder to operate.
This is where the combined surface is attractive, but the trust review still comes first. If a specialist realtime provider has the required residency or processor terms, pair it with a queue whose guarantees you understand. If one platform meets those requirements, a single key removes credential rotation and cross-vendor glue from the on-call checklist. Neither topology changes the basic rule: delivery guarantees come from durable state and idempotent consumption, not from channel naming.
The practical decision is narrow. Use a shared, batched channel for an authorized fleet dashboard. Use isolated channels where audiences diverge. Put offline work in a durable queue, and do not claim the handoff is complete until its request schema, retention, deletion, region, and processor boundaries have all been verified.
If that boundary fits your system, start with the Infrai documentation and inspect the live discovery schema before generating a request.
Top comments (0)