Realtime Systems

Written by Backbone Tutorials Team

Last updated: June 2026 · 10 min read

Open a document a colleague is editing and watch their cursor move, their text appear, their name light up in the corner. Nothing about that experience fits the request-response model the web was built on, where the browser asks and the server answers. Realtime systems flip that around so the server can speak first, and building one means solving a cluster of new problems: how data arrives, how many clients stay in agreement, and what happens when the network misbehaves. This guide is the engineering overview of that world, the architecture behind collaborative editors, chat, and live dashboards.

It extends the events thinking in event-driven UI and the shared-state ideas from state management into the realtime setting.

What makes a system realtime

The defining trait is direction. In an ordinary app the client initiates every exchange; in a realtime one the server can deliver updates the client never asked for, the moment they happen.

From request-response to push

That ability to push, combined with low latency, is what lets a shared view reflect other people's actions live. The architectural consequence is that your UI must be ready to update at any time, not only after its own requests, which is why the event-driven style underpins every realtime app. Once you accept that updates can arrive unprompted, the rest of the design is about delivering, merging, and surviving them.

Transport choices

Before anything can be pushed, you need a channel that supports it, and the platform offers several with different shapes. Choosing well starts with the direction and frequency of your messages.

Polling, SSE, WebSocket, WebRTC

// A persistent two-way channel; updates arrive as messages
var socket = new WebSocket('wss://example.com/live');
socket.onmessage = function (e) {
  applyUpdate(JSON.parse(e.data));
};

Polling repeatedly asks the server for changes and is simple but wasteful. Server-Sent Events open a one-way stream from server to client, ideal for feeds and notifications. WebSocket, shown above, is a persistent two-way channel, the workhorse for chat and collaborative editing where the client sends often too. WebRTC adds peer-to-peer data channels for the lowest-latency direct connections. Pick the lightest transport that covers your direction and latency needs rather than defaulting to the most powerful.

Keeping clients in sync

A transport moves messages, but the real challenge is keeping many clients agreeing on one shared state. When several people change the same thing, those changes have to converge.

Broadcasting state to many clients

The basic loop is that a client sends a change, the server applies it to the authoritative state and broadcasts it to everyone else, who apply it to their local copy. The hard part is conflict: two people editing the same place at once. Simple apps let the server serialize changes and last-write-wins; collaborative editors reach for conflict-free replicated data types or operational transforms so concurrent edits merge without losing work. Either way, the goal is convergence, every client ending in the same state.

Optimistic updates and reconciliation

Even on a fast connection, waiting for the server to confirm every action makes an interface feel sluggish. Realtime apps hide that latency by acting first and confirming after.

Apply locally, reconcile with the server

// Show the change now; reconcile when the server replies
applyLocally(change);
send(change).catch(function () {
  rollback(change); // server rejected it, undo
});

An optimistic update applies the change to local state immediately so the UI responds at once, then reconciles when the server answers, keeping it if confirmed and rolling back if rejected. This is what makes typing in a shared document feel instant despite the round trip. The discipline is to treat the server as the source of truth, so a local guess that turns out wrong is corrected cleanly rather than left to drift, the reconciliation half being as important as the optimism.

Presence and awareness

Collaboration is not only about shared data; it is about seeing each other. Presence is the layer that shows who is here and what they are doing.

Cursors, typing, and online status

Presence covers who is online, where their cursors are, what they have selected, and whether they are typing, the ambient awareness that makes a space feel shared. This state is ephemeral and high-frequency, so it is usually kept separate from the durable document data and broadcast on its own lighter channel, often without being persisted. Throttling cursor and typing updates, as the event-driven UI guide advised for noisy events, keeps presence smooth without flooding the connection.

Resilience: reconnection and ordering

Realtime connections live on imperfect networks, so they will drop, stall, and deliver messages in the wrong order. A realtime system is only as good as its behaviour when things go wrong.

Reconnecting and resyncing cleanly

When a connection drops, the client should detect it, reconnect with an increasing backoff so it does not hammer the server, and then resync, either by replaying the messages it missed or by re-fetching a fresh snapshot. Because messages can arrive twice or out of sequence around a reconnect, design handlers to be idempotent and to order updates by a sequence number or version, so applying the same change twice is harmless. Handle this well and a brief network blip becomes invisible to the user instead of corrupting their state. The next guide builds on this to look at interactive applications more broadly.

Read next: back to the Frontend Architecture hub, or revisit event-driven UI for the reactions realtime relies on.