Real-time without the polling: how our chat stays live

A chat app lives or dies by how immediate it feels. If a message takes three seconds to appear, the conversation stalls. The obvious fix — poll the server every couple of seconds — works, but it wastes bandwidth, drains laptop batteries, and still adds a visible lag.

One stream per workspace

Instead, every open workspace holds a single Server-Sent Events connection. The server pushes tiny change signals— “a message landed in #engineering” — and the client revalidates exactly the data that changed. No payloads fly over the wire on the hot path, so the same event can fan out to a hundred tabs cheaply.

Signals, not payloads

Why signals? Because what each person sees is different: whether you reacted, what’s unread for you, which threads youfollow. Pushing a rendered message to everyone would be wrong for everyone but the sender. A signal says “this changed”; each client re-fetches its own view.

A self-healing fallback

Networks drop. If the stream dies, a long background revalidation still catches up eventually, then the stream reconnects and instant delivery resumes. You get the responsiveness of push with the resilience of pull — and nobody sits there hammering the server every two seconds.