Real-Time Backend Mistakes That Break Apps at Scale

Almost every real-time backend I have seen fail did not fail because the feature was wrong. It failed because of a handful of predictable mistakes that are invisible in a demo and fatal under load. The demo has ten users on one server. Production has ten thousand across a fleet, and every shortcut you took becomes an incident.

Here are the mistakes I see most, in the order they tend to take an app down.

Mistake one: holding connection state in one process

The most common one. You put session state, subscription lists, and presence in the memory of the process holding the socket. It works because in the demo everything is on one node.

Then you scale out and a message on node A cannot reach a client on node B, because node A does not know that client exists. Or you deploy, the process restarts, and every socket it held drops at once. State that lives in one process makes that process precious, and precious processes are single points of failure that you deploy over regularly.

The fix is to push shared state into a backbone that any node can read, and treat every node as disposable. I make this same argument about scaling WebSockets past one node: if losing a node corrupts the picture, you never actually scaled.

Mistake two: trusting the disconnect event

Sockets do not close cleanly on real networks. A phone loses signal and the connection is dead, but your server waits thirty seconds or more to find out. If you mark users offline only on the close event, your presence data fills with ghosts and your resource cleanup never runs.

The fix is heartbeats and expiring state. Treat silence as death after a timeout instead of waiting for a goodbye that may never arrive. Any presence or session record should have a time to live that a heartbeat renews.

Mistake three: no message durability

The demo sends a message and the client receives it, so delivery looks solved. It is not. What happens when a client is disconnected for two seconds during the send? On a fire-and-forget system, that message is gone forever, and the user never knows they missed it.

Real-time does not mean unreliable. You have to decide, per message type, whether it can be dropped or must be delivered. A cursor position can be dropped, the next one is coming. A chat message cannot. That means a queue or buffer that holds messages for a disconnected client and replays them on reconnect. Deciding delivery guarantees deliberately is the whole point I make about message delivery in real-time apps.

Mistake four: authorizing only at connect time

A request and response backend checks authorization on every request because every request is new. A WebSocket connects once and lives for hours. If you only check permissions at connect time, you have opened a long-lived channel that keeps working even after the user's access should have been revoked.

Every message on a socket is an action. Authorize every message, not just the handshake. A long-lived connection is a long-lived attack surface, and treating it as trusted after connect is how you leak data you thought was protected. This is the same governance discipline behind building guardrails into a product: know who did what and whether they were allowed, on every action.

Mistake five: no backpressure

A fast producer and a slow consumer is a bomb with a timer. If your server pushes updates faster than a client can receive them, the buffer grows, memory climbs, and the node falls over. One slow mobile client should never be able to degrade the whole node.

The fix is backpressure: detect when a client is falling behind and either slow the stream, drop droppable messages, or disconnect the client cleanly. Unbounded buffers are how a single bad connection takes down everyone else.

The pattern behind all five

Every one of these mistakes is the same root error: treating real-time like request and response with a longer connection. It is not. It is a stateful, long-lived, multi-node distributed system, and it has to be designed as one from the first line.

That is why I do not rebuild this stack per product. A complete real-time backend like AltoHost exists to own these exact guarantees, connection lifecycle, delivery, presence, per-message auth, and backpressure, so the app on top inherits them instead of rediscovering them in an outage. It is the same reasoning behind owning the infrastructure my products depend on rather than gluing it together under deadline.

Closing

None of these failures are exotic. They are all the predictable result of building for the demo instead of for load. Design for disposable nodes, expiring state, deliberate delivery, per-message auth, and backpressure, and your real-time backend survives its own success. Skip them and you will meet each one, one incident at a time.