Why Google Calendar Booking Systems Double-Book

Conclusion first: The classic check-then-insert pattern always creates a race condition because of Google Calendar’s eventual consistency. LockService alone is insufficient; you need a dedicated slot-ledger sheet, idempotency keys, and post-insert verification against the Calendar event ID.

1. Exact mechanism of double-booking

2. Race-condition analysis of check-then-insert

3. Limits and correct usage of LockService

4. Slot-ledger sheet design

Column	Type	Purpose
slot_id	string	YYYYMMDD-HHMM-RESOURCE
status	string	FREE / RESERVED / COMMITTED
idempotency_key	string	UUID or hash
calendar_event_id	string	Returned by Calendar API

Checklist:

• UPDATE row under lock
• Record COMMITTED only after successful Calendar insert
• Rollback + retry on failure

5. Idempotency-key code skeleton

function bookSlot(slotId, userId) {
  const lock = LockService.getScriptLock();
  if (!lock.tryLock(30000)) throw new Error('lock timeout');
  try {
    const key = Utilities.getUuid();
    // 1. check FREE in sheet
    // 2. Calendar.Events.insert
    // 3. write COMMITTED + key
  } finally { lock.releaseLock(); }
}

6. Calendar eventual consistency and failure modes

7. When not to use this approach

Final review criteria

The useful question is not how many features the automation has. It is whether the workflow can be understood, recovered, and safely rerun after something goes wrong.

• Raw input is separated from the human-facing working view.
• Each run records success, failure, processed count, and error message.
• Replaying the same input does not create duplicate results.
• Permission changes, quota errors, and external API failures are visible later.

For low-risk internal tasks, that may be enough. For customer replies, booking confirmation, inventory updates, payments, or legal records, the threshold is higher: compare Apps Script against a dedicated SaaS or a small server-backed system before relying on it.