Real-Time Data Synchronization: Architecture Decisions That Actually Matter

Modern applications are expected to behave like live systems. Users do not refresh pages to see updates — they expect the interface to reflect reality the moment it changes. Delivering that experience reliably is an architectural problem, not a UI one.

This article covers how we approach real-time synchronisation in production systems: the patterns we use, the trade-offs we navigate, and the mistakes worth avoiding before they become expensive.

The Problem with Polling

In a traditional REST-based setup, the client periodically asks the server whether anything has changed. This works — until it doesn't. At low scale and low update frequency, polling is simple and predictable. But as user counts grow and data changes more frequently, the cracks appear quickly.

The issues are structural, not incidental:

• Server load scales with connected users, not data activity Every client generates a constant stream of requests whether or not anything has changed. You are paying for noise.
• UI consistency degrades under concurrency When multiple users act on the same records simultaneously, stale state causes conflicts. In scheduling systems or workflow tools, this is a real operational problem — not just a visual one.
• Latency is baked in Even with aggressive polling intervals, updates arrive late by definition. The client is always reacting to the past.

The right response to these problems is not tighter polling intervals or smarter caching layers. The architecture needs to flip: rather than clients pulling, the server should push.

A Streaming Architecture Built Around Change Streams

The approach we use centres on a direct connection between database mutations and the client interface, with no polling in the middle. The key components are Express as a streaming layer, MongoDB change streams for detecting mutations, and React on the frontend handling incoming updates efficiently.

The flow in practice:

• A user performs an action — booking a session, updating a record, changing a status.
• Express handles the request and writes to MongoDB.
• MongoDB emits a change event via its native change stream API.
• The backend filters the event by relevance and pushes a structured update to connected clients.
• React updates the affected parts of the UI without a page refresh — or a full re-render.

Choosing Between SSE and WebSockets

The transport layer choice matters. Server-Sent Events (SSE) and WebSockets solve different problems, and conflating them is a common mistake.

SSE is a unidirectional, HTTP-native protocol. The server streams events to the client over a persistent connection. It is lightweight, reconnects automatically, and works without additional infrastructure. For most dashboard and notification use cases — where the client is consuming updates rather than sending them — SSE is the better choice.

WebSockets provide bidirectional communication over a persistent TCP connection. The overhead is higher, and they require more careful handling of connection state, authentication, and reconnection logic. We use WebSockets when the client genuinely needs to send a high volume of messages back to the server — collaborative editing, real-time input sharing, live cursor tracking.

Defaulting to WebSockets for everything is a common over-engineering trap. Start with SSE, and reach for WebSockets only when the communication model genuinely requires it.

MongoDB Change Streams: What They Give You

MongoDB's change stream API lets you subscribe to a collection — or a specific document — and receive events whenever data is created, updated, or deleted. Crucially, this happens at the database level, not the application level. You are reacting to what actually happened in storage, not to what your application believed it wrote.

We apply targeted filtering before emitting events to connected clients. Not every update is relevant to every user. Filtering by collection, document ID, or user-scoped criteria at the source keeps network traffic minimal and avoids unnecessary rendering cycles downstream.

This also avoids the need for a separate event bus or message queue for many use cases. The database becomes the source of truth for both state and events — which it already was, implicitly. Change streams just make that explicit.

Frontend: Handling Live Data Without Degrading Performance

Receiving real-time updates is only half the problem. If the frontend handles them naively — replacing entire datasets, triggering full re-renders — the performance characteristics of a live system can actually be worse than polling.

Surgical State Updates

Rather than replacing an array when a single item changes, we patch the specific item in normalized state. This keeps React's reconciliation work proportional to what actually changed, not to the size of the dataset. In dashboards with dozens of live records, this distinction is significant.

Selective Re-renders

We use lightweight state libraries — Zustand, or Context with careful memoisation — rather than lifting all streaming state into a single global store. Combined with React.memo, useMemo, and useCallback, this ensures that a data update for one record does not cause unrelated components to re-render.

The goal is that the cost of a real-time update, on the frontend, should be as close as possible to the cost of the change itself — not the cost of the entire view.

The Edge Cases You Cannot Ignore

Real-time systems introduce failure modes that do not exist in request-response architectures. Treating them as afterthoughts leads to systems that work beautifully in development and behave unpredictably in production.

• Reconnection Connections drop. The client needs to reconnect cleanly — with exponential backoff — and reconcile any missed events without duplicating state.
• Deduplication During reconnection windows, the same event can be received more than once. Events need idempotency keys so the frontend can discard duplicates safely.
• Race conditions When two users modify the same record near-simultaneously, the order in which the frontend receives updates matters. Optimistic UI patterns need to account for server-side resolution.
• Authorization at the stream level Streaming endpoints need the same authentication rigour as REST endpoints. Token validation, scope-based filtering, and role checks should happen before any event is emitted — not after.

When Real-Time Architecture Is and Isn't the Right Call

Not everything needs to be live. Adding real-time infrastructure to a system that does not require it adds complexity without adding value. The decision should be driven by actual user and operational requirements.

• Good fit Scheduling and booking systems where conflicts from stale state have real consequences. Collaborative tools where multiple users work on shared records. Operational dashboards where latency directly affects decisions.
• Probably not necessary Reporting and analytics views where data changes infrequently. Admin interfaces used by a single operator. Content management systems where near-real-time (via ISR or short cache TTLs) is sufficient.

The cost of real-time infrastructure — in complexity, operational overhead, and edge case handling — is real. It is worth paying when the alternative is a user experience that cannot be made acceptable any other way.

The Core Mental Model

The shift from polling to streaming is not primarily a technology change — it is a change in how you think about data flow responsibility. In a polling model, the client owns the update cycle. In a streaming model, the server owns it. Data moves from the source of truth outward, rather than being pulled inward by consumers on a timer.

Once that model is internalized, the technology choices — SSE vs WebSockets, change streams vs a message queue, Zustand vs Context — become implementation details that follow naturally from the requirements. The architecture question comes first.

Stop Polling. Start Streaming.

If you're building a SaaS product or internal platform that needs real-time data sync — whether that's live dashboards, collaborative workflows, or conflict-free scheduling — we've done this before and we can help. Get in touch and let's talk about what your system needs.