Why we don't do nightly syncs

Batch synchronisation is the obvious architecture. It is easier to build, easier to reason about, easier to retry, and it is what most integrations quietly do regardless of how the marketing describes it. It is also wrong for scheduling, and the reason is not performance.

A sync produces a copy. The moment you have a copy, you have two systems that believe they know the state of the diary, and they are only in agreement between syncs. Every scheduling decision made against the copy is a bet that nothing changed on the other side. Most of the time you win that bet. When you lose it, a patient arrives for an appointment that a human scheduler took twenty minutes after the last sync ran, and the resulting conversation costs more than the integration saved that week.

You can shrink the window - hourly, five-minutely - but you cannot close it, and each reduction costs more in API load than the last. The window is structural.

Reading at the point of decision removes the class of bug rather than reducing its frequency. It costs a round trip inside a call that is already a live phone conversation, which is latency nobody notices, and it means the agent is never operating on a belief about the schedule - only on the schedule. The trade is that you inherit whatever the source system's availability is, including its quirks, which is the correct thing to inherit.

We do use asynchronous work for things that are genuinely asynchronous: outbound campaigns, recall lists, reminder scheduling. Those have no race condition because nothing else is competing to write the same row.

The platform covers the architecture at a higher level, integrations lists what we connect to, and trust and compliance has the data handling detail your security review will ask for.

How it connects

Real time

Written while the patient is still on the line. Every write logged and reversible.