Running Our Own Realtime Updates With a Polling Safety Net

Some features need to update the moment something changes. A chat message should appear for everyone in the room right away. A notification bell should light up when something needs attention. A live video page should show viewer activity as it happens. Refreshing the page every few seconds is wasteful and slow; a realtime connection is the better tool.

We run our own realtime update service rather than relying on an outside push service. Here is why, how it works and how we keep pages working when connections are imperfect.

Why run our own

Outside realtime services are convenient and reliable, and for many teams they are the right choice. For us, a few reasons tipped the balance toward running our own:

• Fewer outside dependencies. Realtime updates are part of many features, so depending on another company for them adds risk across the platform.
• Data stays on our infrastructure. Messages and events are handled by our own servers rather than a third-party push service.
• Cost that scales with us. Usage-based pricing for realtime connections can grow quickly with live features.
• Fits our framework. Our web framework has a well-supported realtime server that runs alongside the application and uses the same broadcasting patterns developers already know.

It is a good example of a decision we explain in build, reuse or buy: realtime is central enough to our live features that owning it made sense.

One shared way to use it

Modules do not talk to the realtime service in their own ways. A shared service handles publishing events, preparing the connection details a page needs and authorizing private channels. Pages connect with one shared client library. That keeps behavior consistent and makes it easy to add realtime updates to a new module correctly.

Private channels are authorized

Some updates are public, such as the viewer count on a public live page. Others are private: a team workspace, a member's notifications or a chat restricted to members. Private channels require authorization: before a page can listen, the server checks that the person is allowed to receive those updates and signs the permission. A visitor cannot subscribe to a private channel by guessing its name.

A polling safety net

Realtime connections drop. Phones switch networks, laptops sleep and firewalls interfere. If a page relied only on its realtime connection, those moments would leave it silently out of date. So every page that uses realtime updates also has a slower polling fallback: every so often, it checks for changes the ordinary way. When the realtime connection is healthy, polling adds little. When it is not, polling keeps the page correct.

Publishing never breaks the action

Sending a realtime update should never cause the action behind it to fail. If a chat message is saved but the realtime service is briefly unavailable, the message is still saved and will appear through polling. Our publishing helper is designed not to throw errors back into the action that triggered it.

Watched and restarted

The realtime service runs alongside the application, is checked regularly and is restarted after each release so it uses the new code. If it stays down after restart attempts, or a release leaves it down for too long, or the scheduled check itself stops running, our administrators receive an urgent notification, and another when it recovers. A realtime service that fails silently would undermine every feature built on it. That fits the broader checks in what we check after every release.

Capacity is planned

Every open page with a realtime connection uses resources. We know the current connection capacity of our setup and plan improvements before live features approach it. Growth should be a planned upgrade, not a surprise outage during a popular broadcast.

Frequently asked questions

What are realtime updates?

Realtime updates push changes to an open page instantly, such as new chat messages or notifications, instead of waiting for the page to be refreshed.

What happens if the realtime connection drops?

Pages fall back to checking for changes periodically, so they stay correct even when the instant connection is interrupted.

Can someone listen to private updates they should not see?

No. Private channels require the server to authorize each person before a page can receive their updates.