Why we self-host real-time notifications instead of using a third-party vendor

A lot of dashboards check for new notifications by polling — asking the server "anything new?" on a timer, every few seconds, for every open tab. It works, but it isn't instant, and the database load adds up as more people are online at once. The better approach pushes an update the moment something happens, instead of everyone constantly asking.

That kind of real-time delivery is usually bought from a third-party vendor — a hosted push-notification or realtime-messaging service. We chose to run that piece of infrastructure ourselves instead. It's more work upfront, but it means no per-connection billing from a vendor as usage grows, no dependency on a third party's uptime for a feature our own customers rely on, and no customer data passing through another company's servers on its way to being delivered.

The part that's genuinely tricky

Adcoar Tours is multi-tenant — every tour operator gets their own separate space in the product. Most write-ups of self-hosted realtime infrastructure assume a single-tenant app talking to a single fixed backend address, which is the easy case. Making it work correctly when every customer's traffic needs to be routed to the right place, without that routing being hardcoded per customer, took real design work — the kind of problem that only shows up once a system has more than one customer using it at once, and doesn't show up at all in a demo.

Knowing when it's actually working

Infrastructure like this can fail quietly — a dead connection doesn't throw an error a user notices, notifications just start feeling a bit slower to arrive, which is easy to miss until someone complains. We built monitoring specifically for this piece, separate from our general uptime checks, so a problem here shows up as a clear signal on an internal dashboard rather than a vague "things feel off" support ticket days later.