How to Evaluate a Real-Time Backend Provider

When you evaluate a real-time backend, do not start with the SDK demo. Every provider has a slick demo where a message moves from one browser to another in a second. That proves nothing. The demo shows the easy 20 percent. What you are buying is the hard 80 percent: what happens under load, across deploys, when connections die dirty, and when a client is offline at the wrong moment. Judge providers on the answers to those questions, not the animation on the homepage.

Here is the checklist I use, roughly in the order that matters.

Does it handle presence properly

Ask exactly how presence works. The right answer involves heartbeats and expiring state, not just connect and disconnect events. If a provider marks users offline only when the socket closes cleanly, their presence data fills with ghosts on real networks, because sockets die silently all the time. I break down why in building a presence system that feels live.

Follow up with multi-device. Can the same user be present on a phone and a laptop at once, tracked as sessions and rolled up correctly. If presence is a single boolean per user, it is a toy.

What are the delivery guarantees

This is the question that separates real infrastructure from a broadcast toy. Ask what happens to a message sent while a client is disconnected for two seconds.

A serious provider lets you choose per message type. Some messages can be dropped, a cursor position, the next one is coming. Some must be delivered, a chat message or an order update. If the only mode is fire and forget, you will silently lose data and never know. Delivery semantics are a decision you should get to make on purpose, which is the case I make in message delivery guarantees for real-time apps.

How does it scale across nodes

Ask how the system behaves when you outgrow one server. You want to hear about a pub/sub backbone where nodes are disposable and no single process holds precious state. If the answer is vague, or worse if it is "we scale vertically," you are looking at a ceiling you will hit without warning.

Then ask what happens during a deploy. The right answer is graceful draining, where connections migrate to healthy nodes before a restart. The wrong answer is that deploys drop sessions and clients reconnect. A provider that cannot ship code without disrupting every user has not solved the operational half of the problem I describe in scaling WebSockets.

Can you authorize every message

A WebSocket connects once and lives for hours. Ask whether you can enforce authorization on every message, not just at the handshake. A long-lived connection is a long-lived attack surface, and per-message auth is the difference between a governed channel and an open pipe that keeps working after access should have been cut. This is a governance requirement, not a nice to have.

What does pricing do as you grow

Get the pricing model in writing and model it at ten times your current scale. Real-time pricing often keys on concurrent connections, messages, or both, and the curve can bend sharply against you as you grow. This is the same trap I warn about with managed cloud bills that climb. A price that is fine at launch can become the reason you have to migrate later, so know the shape now.

Also ask about lock-in. How hard is it to leave. If the entire application logic ends up encoded in their proprietary primitives, the switching cost is your real price, not the monthly invoice.

Does the whole thing hang together

The last question is the most important and the hardest to test in a trial. Are these features one coherent system, or a bag of parts you assemble yourself. Presence, delivery, scaling, and auth have to be designed together, because they interact. A provider that ships them as unrelated modules has handed you the integration project you were trying to avoid.

That coherence is exactly what I built AltoHost around: a complete real-time backend where the connection lifecycle, delivery, presence, and scale are one governed set of guarantees, not a pile of primitives. Complete is the operative word, and it is the thing to actually test for.

Closing

Ignore the demo. Run the checklist. Presence by heartbeat, delivery you can choose, disposable nodes, graceful deploys, per-message auth, honest pricing at scale, and a system that hangs together as one. A provider that answers all seven cleanly is real. One that dodges any of them is a demo wearing a backend costume.