I built an appointment booking bot for a dental clinic. It managed their calendar automatically.
On the first morning it went live, forty seven appointments were scheduled on top of already booked time slots.
Two patients showed up for the same 9 AM slot. Then three more at 9:30. Then four at 10 AM.
The receptionist called me screaming.
The Setup
This was a dental clinic with three dentists handling appointments through WhatsApp, phone calls, and walk-ins. They wanted automation so a WhatsApp bot could handle bookings twenty four seven, check availability, confirm appointments instantly, and sync everything with Google Calendar.
This was a standard booking flow. I had built similar systems before. We deployed on Sunday night for a Monday morning launch.
The Monday Morning Chaos
At 9:00 AM a slot was already booked for Dr. Ahmed. The bot booked Mrs. Rahman through WhatsApp at 8:47 AM. A few minutes later, at 8:52 AM, a walk-in booking added Mr. Karim to the same slot.
At 9:30 AM, a slot for Dr. Hasan was booked by Ms. Sultana through WhatsApp. Then a phone booking added Mr. Habib. Then another WhatsApp booking added Mrs. Begum.
By 11 AM there were forty seven double and triple bookings. The waiting room was packed and patients were angry.
Why This Happened
The logic looked correct on paper. When a user requested a slot, the bot checked the calendar. If the slot looked free, it confirmed and booked it. If not, it suggested the next available time.
The problem was timing.
Booking confirmation took about three seconds. Calendar synchronization took between five and eight seconds.
That gap was enough to break everything.
The Race Condition
When the first patient requested a slot, the bot checked the calendar and saw it as free. It immediately confirmed the booking to the patient. Only after that did it start writing the event to Google Calendar.
Before the calendar finished updating, another booking request came in. The calendar still showed the slot as available. The second booking was accepted. Sometimes a third followed.
In those few seconds between confirmation and persistence, the slot looked free to everyone else.
Why Testing Didn’t Catch It
During testing, bookings came in slowly. One request per minute. Everything worked fine.
On Monday morning, real traffic hit. Ten booking requests per minute. WhatsApp messages, phone calls, walk-ins, all happening at once.
The system behaved correctly in isolation and failed completely at scale.
The Failed Fix
My first attempt was to wait for the calendar write to complete before confirming the booking to the user.
That made things worse.
Users waited fifteen to twenty seconds without feedback. They assumed the bot was broken and sent the same request again. That created even more overlapping booking attempts.
The Real Solution
I added an instant locking layer.
As soon as a user requested a slot and the calendar check passed, the bot immediately locked that slot in its own database. This lock happened in a fraction of a second.
While the lock was active, the bot treated the slot as unavailable for everyone else. Only after the calendar write succeeded did the lock turn into a confirmed booking.
If another request arrived while the lock was active, the bot suggested the next available time instead.
How It Worked in Practice
When Mrs. Rahman requested the 9 AM slot, the bot locked it instantly and told her the booking was in progress. While the calendar write was happening, Mr. Karim requested the same slot. The bot saw the lock and rejected the request, offering 9:30 instead.
Once Google Calendar confirmed the booking, the lock was released and the slot was officially marked as booked.
No overlap. No confusion.
Edge Cases We Had to Handle
Locks couldn’t live forever. If a calendar write failed, the slot would stay blocked. To prevent that, every lock expired automatically after thirty seconds.
If a user cancelled during the booking process, the lock was released immediately.
Because bookings could come from WhatsApp, phone, or walk-ins, every system checked the same lock store before confirming anything.
If the lock system itself failed, the bot entered a safe mode and temporarily rejected all bookings instead of risking corruption.
The Results
In the first week after the fix, there were zero double bookings. The bot prevented thirty four conflicts that would have turned into overlaps. Average confirmation time stayed just over two seconds.
Before the fix, there were forty seven double bookings in three hours. After the fix, there were none in three months.
The receptionist stopped manually verifying bot bookings. Patient trust recovered. The bot now handles most of the clinic’s bookings reliably.
What I Learned
Calendar sync is never instant, no matter how real time it sounds. Fast user responses and slow database writes must be treated as separate systems.
Race conditions don’t show up during light testing. They appear only when traffic increases.
The simplest fix was not smarter AI. It was a two layer system that acknowledged reality. One fast layer for locking and user experience, and one slow layer for permanent records.
The Bottom Line
Forty seven double bookings happened because I assumed calendar sync was instant.
The fix was a lock that takes two tenths of a second.
That small change turned chaos into a stable system that now runs hundreds of bookings without conflict.
Written by FARHAN HABIB FARAZ, Senior Prompt Engineer and Prompt Team Lead at PowerInAI
Building AI systems that handle real world timing issues.
Tags: bookingautomation, raceconditions, scheduling, automation, systemdesign, calendarsync
Top comments (0)