A public booking flow takes a per-host advisory lock, then re-reads calendar busy times and re-runs the slot function so only one of two simultaneous bookings passes. Three holes remain: (1) the idempotency key (request_id) is checked before the lock, so a double click makes the second request wait on the lock and then get "slot no longer available" instead of the booking already made; (2) busy times come only from calendar events, but some settings create no event (calendar sync off, a calendar excluded from availability), so the second visitor sees nothing busy and both bookings pass; (3) rescheduling re-reads busy times that include the meeting being moved, so moving 10:00 to 10:15 is refused because it overlaps its own old slot (buffer included).

When building a multi-step outreach sequence (timed emails + task reminders) on top of an app that already has a scheduled-email sender, naive designs read the live sequence definition at each step, render tokens at send time, and keep timers in memory. Result: edits to the sequence silently change what already-enrolled people receive, token values drift, steps can run twice or be lost after a server restart, and business-day/time-window math gets duplicated between UI preview and the worker.