Booking Runtime: Forms and Availability at Scale

SpiderPublish treats forms and booking flows as first-class entities, not plugins. Both share the same underlying model — a booking_flows row in PostgreSQL with a kind discriminator — but serve fundamentally different user experiences. Here is how we built a runtime that handles both at scale.

The Unified Model

A form with kind=form is a standard lead capture: name, email, phone, message, custom fields. A form with kind=booking adds date and time selection, staff assignment, availability checking, and calendar integration. Both render at the same URL pattern — /f/{id} — and both use the same submission pipeline. The kind column determines which UI components are rendered and which backend integrations are triggered.

Real-Time Availability

For booking flows, availability is checked in real-time against connected calendars. When a visitor opens a booking page, the system fetches available slots from all assigned staff calendars (Google Calendar, Outlook, Cal.com) via OAuth connections, deduplicates conflicts, and presents the merged availability grid. This happens on every page load to ensure visitors never see stale availability data.

Concurrency Control

When two visitors attempt to book the same slot simultaneously, the system uses optimistic locking with a version column. The first submission that reaches the database wins; the second receives a conflict response and is prompted to select a different time. We chose optimistic over pessimistic locking because booking conflicts are rare — typically less than 0.1% of submissions — and the user experience of slot-level locks (where a slot disappears while you are filling in your details) is worse.

Webhook Delivery

Every form submission triggers configurable webhooks with at-least-once delivery. Webhooks include the full submission payload, the form schema, and the tenant context. Failed deliveries are retried with exponential backoff up to five times over 24 hours. After five failures, the webhook is marked as dead and the tenant receives a notification.

The Question Pipeline

Form questions support conditional logic and variable interpolation. A question can be shown or hidden based on previous answers, and its label can include merge tags that resolve from IDAP records, URL parameters, or previous answers. The logic engine evaluates conditions client-side for instant feedback, then re-validates server-side on submission to prevent bypass.