Why Nightly Syncs Cause Double Bookings

A nightly sync copies the practice diary once a day. By four in the afternoon that copy can be sixteen hours old, which on a live call is not a delay but a wrong answer: the agent offers a slot that was taken this morning, confidently and specifically, because the copy it reads still shows it as free.

This comes up in almost every technical conversation about integration, usually as a sensible-sounding question about load. Would it not be gentler on the practice system to pull the diary overnight and answer from that? It would. It would also be wrong in a way that stays invisible until it is embarrassing.

16 hours

the age of a nightly copy by late afternoon

480 ms

the reply budget the live read fits inside

6

stages in a booking that all depend on a current read

95+

integrations 2care reads live rather than mirroring

A system reading a stale copy does not hesitate, hedge or report uncertainty. It has data, the data says the eleven o'clock is free, and it says so. The caller accepts. The write then either fails, and the conversation has to be unwound, or it succeeds into a double booking, and two patients arrive for one slot that the practice discovers on the day.

Compare that with a system whose live read is merely slow. That failure is visible at once, it is annoying, and it is safe. Given the choice between a system that is occasionally slow and one that is occasionally confidently wrong, take the slow one every time.

The timeline is ordinary. A receptionist books the eleven o'clock at half past nine at the desk. The nightly copy, taken at two that morning, still shows it free.

A caller rings at noon, is offered eleven, accepts, and now two people hold it. Nobody was careless. The copy was simply asked a question it could no longer answer.

The principle underneath is simple. In a real-time conversation a cache is not a faster read. It is a different answer.

Where a nightly sync is the right tool

Batch synchronisation is not a bad pattern. It is a bad pattern for this one thing.

Use	Freshness needed	Batch appropriate
Reporting and analytics	Hours to days	Yes, the right choice
Reconciliation and audit	Daily	Yes
Recall list generation	Daily	Usually
Availability during a live call	Seconds	No
Writing a booking	Immediate	No

The top rows are what integrations were historically built for, which is why the nightly habit is so entrenched. It became the default when the job was moving data between systems overnight, and it is good at that. The phone call is a different problem, and carrying the assumption across is where it goes wrong. Recall campaigns are the interesting middle case: our proactive outreach reads the recall list in batch and still checks each slot live before it offers one.

The second source of truth

There is a cost to a mirror beyond staleness, and it persists long after someone has narrowed the freshness gap with more frequent syncing.

A copy of the diary is a second place an appointment can be said to exist. Once two systems both hold appointments they can disagree, and something has to decide which is right. That reconciliation is not a feature anyone asked for. It is permanent operational work the architecture created, and it grows with volume.

Practices meet this as a class of problem with no clean owner. An appointment is in one system and not the other. Nobody did anything wrong. Somebody has to go and look.

The work is small per incident and relentless in aggregate. One mismatch takes a receptionist a few minutes to chase: open both systems, work out which booking is real, correct the other, and hope nobody rang in between. Multiply that by the number of times two diaries drift in a busy week and it becomes a standing task on someone's list, created by nothing anyone did and removed by nothing short of collapsing the two copies back into one.

What 2care reads, and when it will not answer

Availability is read from the practice system at the moment the caller asks, and the booking is written into that same system during the call. It reads over each system's official API, native rather than through a separate voice platform, across the 95+ integrations 2care connects to and any HL7 FHIR R4 endpoint beyond them. There is no mirrored diary and no overnight reconciliation job, which is the same decision behind how write-back works.

Two consequences follow, including an uncomfortable one. When the practice system is slow, the call is slower, because the read is real and still has to land inside the roughly 480 millisecond budget the agent replies in. And when the practice system is unavailable, 2care cannot offer availability and says so, rather than falling back to a copy and producing bookings that will need reconciling later.

That second behaviour looks worse in a demo and is better in production. A system that keeps taking bookings during an outage is not more resilient. It is deferring the failure into a form a person has to clean up by hand.

Making a live read fast enough

The objection to reading live is usually speed, and it is worth answering with the mechanics rather than a reassurance. Three things keep a live availability read inside a conversational budget.

Only availability is fetched live. Reference data that barely moves, appointment types, clinician lists, room and resource names, is cached and refreshed on a slow schedule, because none of it changes between the question and the answer. The one thing that does change, whether a given slot is still free, is all that gets read fresh on the call.

The read starts early. The request for availability goes out while the agent is still confirming what the caller wants, so its round trip overlaps speech the caller was going to hear anyway rather than adding to the pause. By the time the sentence that offers a time is due, the answer is usually already back.

Connections are kept warm. A live read per call is many more requests than a nightly pull, so the connection to the practice API is pooled and reused rather than negotiated from cold each time. That is the difference between a live read that fits the 480 millisecond budget and one that visibly stalls the call.

None of this is exotic. It is the ordinary set of moves for making a networked read feel instant, and it is worth asking a vendor to describe, because one reading live without them will have a slow agent, and one that cannot describe them at all is probably reading from a cache it would rather not mention.

What a stale read costs, in practice

The argument against a mirror is easiest to see when the failure is quantified rather than described.

The double bookings are the expensive half. A correction mid-call is embarrassing. Two patients arriving for one slot costs clinical time and a relationship, and it is the kind of thing a practice remembers longer than it remembers a slow call.

Why a mirrored diary is also a compliance question

A mirror is a second copy of patient information held by a vendor, which has contractual consequences as well as operational ones.

Under HHS guidance a vendor creating, receiving or maintaining protected health information is a business associate rather than a conduit.

A vendor holding a synchronised copy of your appointment book is plainly maintaining it, so the agreement has to cover that store, its retention and its deletion. Reading live does not remove the requirement, since call content is still created, but it shrinks the surface to one diary that belongs to the practice. We set out what that covers on the compliance page.

Where a live read is the wrong design

Three constraints, and the first is a hard stop rather than a trade.

A practice system with no usable real-time read API. Availability cannot be offered live, and the honest fallback is capturing the request for someone to action, described as that rather than dressed up as booking.

Aggressive rate limits. A live read per call is many more requests than one nightly pull, and where a vendor's published API budget does not accommodate your call volume, the limit binds regardless of how good the architecture is. Confirm it during setup, not on your first busy Monday.

A diary that is wrong inside the practice system. Reading live means faithfully reading whatever is there, including the appointment entered against the wrong clinician. No architecture corrects bad data, and resolving the caller to the right record is a separate problem covered in patient matching.

Frequently asked questions

Does reading live add load to our practice system?

More than a nightly pull, and it scales with call volume rather than with the size of your patient list. It is worth checking against your system's published rate limits during setup, because that ceiling, not the design, is the real constraint on this approach.

What happens during a practice system outage?

The agent says availability cannot be checked and captures the request for a person to complete. It does not fall back to a cached diary, because a booking made against a copy during an outage is the hardest kind to reconcile once the system comes back.

Is anything cached at all?

Reference data that changes rarely, such as appointment types and clinician lists, can be. Availability is never cached, because it is precisely the thing that changes between the question and the answer, which is the whole reason live reads exist.

Would syncing every five minutes fix this?

It narrows the stale window without closing it, and it leaves the second-source problem completely intact. A five-minute copy is still a copy, and the reconciliation it creates is still work that someone at the practice has to own.

Does this matter for outbound calls too?

More so. An outbound recall call offering a slot from a stale copy is offering an appointment to a patient who did not ask for one, so a wrong answer becomes a wrong promise made on your behalf, which is harder to walk back.

Ask where the availability came from

There is one question that makes any vendor's architecture visible: at the moment the agent says "eleven o'clock is free", where did that come from and how old is it?

The answers divide into three. Read live from the practice system, which is the position argued here. Read from a cache refreshed on an interval, which is a stale window plus a second source of truth. Or read from a full mirror, which is the same problem at a larger scale. Vendors answer in architecture language; translate it into hours, then decide whether you are comfortable with a patient being told something that old with complete confidence.

See how the live read works per system on the integrations page, or hear an availability check on a real call when you book a demo.