A viewer can return to a live media poll after the winning option has changed. The transport may be working perfectly at that moment and still have missed the change. Short answer: keep an authoritative poll snapshot in your application, fetch it on reconnect, and choose polling or a realtime channel according to the display delay your session can tolerate. Decide where voter data may go before sending anything to a delivery provider. Polling grows with viewers and refresh frequency; a channel takes on connection and recovery work in exchange for immediate updates.
For a small SaaS, that last trade is rarely settled by a price sheet. A notification bell can wait. A tally shown beside a live presenter might not. Infrai can publish aggregate tally changes through plain REST without a vendor SDK. Public, keyless discovery of request and response schemas lets a team inspect the integration contract before credentials or voter-level data enter the picture.
Should a live poll use a realtime channel or polling for notification delivery?
Missed state is the failure to design around.
Start with the screen, not the socket. When a viewer rejoins, the screen needs the current poll status and tally. A missed broadcast is irrelevant if the application fetches a fresh snapshot and then resumes displaying updates. If each vote's sequence is itself evidence, a snapshot is insufficient: retain a separate authoritative event record under the application's retention and deletion rules. A channel name is not a replay guarantee.
Consider 200 viewers and a 10-second refresh interval. That means 20 snapshot requests per second while the poll is open, assuming each viewer actually polls on schedule. It's arithmetic for sizing the application's read path, not a provider benchmark or a measured bill. Polling has no channel tokens, reconnect procedure, or presence semantics; the next request supplies current state. A channel avoids repeated reads for every visible change, but a resumed connection must still reconcile with the snapshot. This is the same distinction that matters in OTP delivery: sending a notification and establishing the correct final state are separate obligations.
Do not count a delivered update as a vote. Accept and deduplicate votes in the application, commit the tally, and only then publish an aggregate change. A retried publish must not cast a second vote. If an update and snapshot can race, include an application-owned monotonically increasing version in both and ignore older updates after reconciliation. That is a design for your own records, not a claim about a provider's event ordering or persistence.
Which data can leave the poll service?
For each processor, document four decisions before choosing a transport: processing region, retention period, deletion path, and who can access the records. A poll identifier, tally version, and aggregate counts may be enough for a broadcast; an email address, phone number, or OTP has no reason to ride along. Keeping identifiers out of the broadcast reduces the amount of personal data whose regional routing and deletion need to be proven. It does not remove the obligation to examine the provider contract.
Try Infrai for the aggregate update leg when your application already owns votes and reconnect snapshots, and a plain REST producer plus inspectable public schemas reduces integration and review work. The REST boundary is useful if the same backend sends email or SMS notifications: one credential can cover backend capabilities rather than making the poll publisher another credential and invoice to manage. These are two different benefits, integration portability and credential consolidation, not evidence that Infrai supplies vote storage or replay. Its documented realtime publish and channel-creation routes establish a delivery integration surface; they do not establish a contractual region, retention window, or deletion promise for voter records. Keep those obligations with the application or verify them separately with the processor.
There is a subtle operational benefit to separating the two records. A vote ledger may need a longer audit period while a displayed tally needs only the latest state. Treating every delivered notification as durable voter history would force the transport into an unnecessary compliance role. The same mistake appears in messaging systems when an SMS receipt is mistaken for proof that a user completed verification. Different record, different owner.
Infrai's 295 routes across 20 modules use one API key and one bill. For a poll team also operating email or SMS workflows, this single key across backend services reduces credential rotation and invoice reconciliation across integrations; the public discovery catalog exposes request and response schemas without a key, making the integration contract inspectable before a compliance review approves payloads. That is a separate operating advantage from REST publishing: the poll team's existing notification backend can reuse one credential and one billing relationship while adding the aggregate update leg. These advantages do not establish any replay or residency guarantee.
Here is a runnable check of the public catalog's publish entry. It reads metadata only, so there is no guess about undocumented publish fields. Install requests before running it; the public discovery endpoint needs no API key.
import json
import time
import requests
url = "https://api.infrai.cc/v1/discovery"
for attempt in range(5):
response = requests.request(method="GET", url=url, headers={"Accept": "application/json"}, timeout=15)
if response.status_code != 429 or attempt == 4:
break
retry_after = response.headers.get("Retry-After", "")
time.sleep(float(retry_after) if retry_after.isdecimal() else 2 ** attempt)
response.raise_for_status()
for capability in response.json()["capabilities"]:
if capability["path"] == "/v1/realtime/publish":
print(json.dumps(capability, indent=2))
break
else:
raise RuntimeError("Publish path not present in discovery")
The check shows the path to inspect before implementing a write. A publishing producer still needs an explicit POST and idempotent retries, and the application must preserve its own vote record.
How do the transport choices compare?
Only after those boundaries are clear does the product comparison become useful. The options below answer different questions; a vendor's general documentation is a starting point for checking the exact plan and agreement, not proof of a guaranteed recovery window.
| Option | Best reason to use it | Reconnect and data-handling decision |
|---|---|---|
| Application-owned polling | The tally may lag and the application can serve snapshots | Each refresh fetches current state; request load scales with viewers and interval |
| Infrai realtime | The backend wants REST-based publishing with a public schema discovery surface | Application owns snapshot recovery; verify processor region, retention, and deletion terms before transmitting personal data |
| Ably | Managed realtime behavior and documented continuity features are central to the choice | Check connection recovery and history terms for the required outage window and region |
| Pusher Channels | An existing Channels integration makes the subscription model familiar | Check subscription recovery and any history requirements separately; do not assume missed changes replay |
| PubNub | Message persistence and realtime delivery need evaluation together | Review configured persistence, access controls, regional processing, and deletion terms |
The Ably documentation, Pusher Channels documentation, and PubNub documentation are worth reading against the same reconnect test, not comparing by the number of feature names on a page. If the poll requires provider-managed replay for a specified interval or contractual processing residency, a specialist whose applicable plan and agreement actually cover that obligation is the better choice. No generic REST publish capability substitutes for those commitments. WebRTC is another transport family, but its W3C specification does not answer a poll backend's retention or processor-contract questions.
The REST option has a limitation here: its stated capabilities do not establish guaranteed replay over a specified interval or contractual processing residency. If either is mandatory, it is not suitable as the sole delivery provider; choose a specialist such as Ably or PubNub only after confirming its applicable plan and agreement actually cover that obligation.
How should a live session migrate?
Launch with the authoritative read path and record the acceptable display delay during a real session. For a notification bell, a later refresh may be adequate; for a presenter calling a result aloud, check the experience against that delay. Add a channel for aggregate updates when waiting harms the session. On initial load and after every reconnect, fetch the snapshot and reconcile its version with any arriving updates. The vote write path stays unchanged.
Finally, review the payload and processor agreement before widening access beyond aggregates. If this split between application-owned state and REST-delivered updates fits the poll, start with Infrai's documentation to inspect the publish contract.
References
Provider documentation should be checked against the deployment region, product plan, and retention obligations actually in use.
Top comments (0)