Real-Time Performance: 3x Faster Updates

Real-time updates are only valuable if they're actually real-time. An update that takes 3-4 seconds to propagate from one user's action to another user's screen isn't truly live — it's a slow refresh cycle with a fancier name.

This update brings propagation latency down to under a second in typical conditions — a 3x improvement over the previous implementation.

Where the Latency Was

Real-time propagation has several stages: detecting a change, determining which connected clients need to be notified, computing the update payload, delivering it to those clients, and rendering the update in the browser.

Each stage contributed to the overall latency. The previous implementation had inefficiencies at several points:

Change detection. The system was polling for changes at a fixed interval rather than responding to changes as they occurred. This polling interval introduced latency at the detection stage.

Client targeting. Determining which connected clients needed to receive an update required a query per change. For high-change-rate operations, this became a bottleneck.

Payload size. Update payloads included more data than needed. Clients received full record states even when only one or two fields had changed.

What Changed

Change detection is now event-driven rather than polling-based. Changes propagate immediately to the notification layer rather than waiting for the next poll cycle.

Client targeting is computed from an in-memory index rather than a per-change query. Updates reach the right clients faster.

Update payloads are now differential — only the changed fields are included, not the full record state. This reduces payload size and browser-side processing work.

The Result

From the moment a field is saved to the moment the change appears on a colleague's screen: typically under 500 milliseconds. Edits to a record, status changes, new comments — all visible to other users within half a second.

Real-time that actually feels real-time.