Scheduling System: Real-Time Booking with Google Calendar Conflict Resolution

Discovery calls are the highest-leverage conversion event in a services business. A missed booking, a double-booked slot, or a four-step scheduling friction is not a minor annoyance. It is a closed deal reverting to silence.

The existing flow at Avo was manual: a prospect submitted a form, received an email, and was asked to reply with a preferred time. Response latency ran 24 to 48 hours. By that point the lead had cooled or found a competitor. The business needed the prospect to lock a slot within minutes of submitting their brief.

The compounding problem was slot integrity. Any static calendar embed would show an optimistic list of open times with no awareness of existing commitments or already-booked discovery calls from concurrent sessions. Real double-bookings were not hypothetical.

The system separated concerns into three independent layers. The first layer was the slot generation engine: a pure computation step producing a 14-day forward window of 30-minute slots across Monday through Saturday, 8:00 AM to 4:30 PM Eastern Time. The second layer was the conflict filter: a parallel fetch of two data sources resolved before any slot was shown. The Google Calendar freeBusy API returned committed intervals for the primary calendar. A ClickHouse query on consulting_bookings returned slots already confirmed by prior bookings. The third layer was the double-booking guard: a slot availability check triggered at click time in the SlotPicker component, re-validating the specific slot against both sources before committing.

On booking submission, the booking hit POST /api/book first, writing a record to argus.consulting_bookings with status = awaiting_slot and generating a UUID booking_id. The prospect was redirected to /schedule?bookingId={id}. When they confirmed a slot, a second endpoint wrote the selected time, updated status to booked, and created the Google Calendar event via the Calendar Events API.

Token management used raw fetch calls with no googleapis package. A stored OAuth2 refresh token was exchanged for a short-lived access token on each request via getAccessToken(), with an 8-second AbortController timeout.

UTC math for overlap detection: slots were generated in Eastern Time but compared against Calendar intervals in UTC. The slotStartUtc() function used a round-trip through Intl.DateTimeFormat to correctly compute the ET offset at a given date, handling both EST (UTC-5) and EDT (UTC-4) without a timezone library. The overlap test was a simple open-interval check: slotStart < b.end && slotEnd > b.start.

The getCalendarBusy function returned an empty array on any error, allowing slot generation to continue with only the ClickHouse guard active. This meant that when Google Calendar was unavailable, the correct behavior was to show all business-hour slots rather than show an error. The prospect still booked. The operator checked their calendar manually if needed.

The full booking flow, from form submission to confirmed calendar event, completed in under 3 minutes for prospects who acted immediately on the schedule link. Slot generation including the parallel Google Calendar and ClickHouse fetches completed in under 800 milliseconds cold. The double-booking guard caught zero actual conflicts in production, which was the intended outcome. Zero dependencies were added to the npm bundle beyond what was already present.