Appointment operations / EngineeringSEPTEMBER 2026

Engineering inside Cadence /

The data model, constraints and recovery decisions behind Cadence.

A light blue calendar workspace brings the week, host filters and appointment details together. The interface preview supports local appointment creation and conflict checks, with a day view on small screens.

01

Interface and interaction architecture

The public interface explores the booking journey with local example state. The private full-stack workspace uses FullCalendar and Luxon alongside server-side availability, hold expiry and appointment conflict checks.

02

Overlap is a server decision

Reservations use absolute start and end timestamps with explicit offsets. Two intervals overlap when one begins before the other ends and ends after it begins; adjacent boundaries remain available. The API evaluates active, unexpired holds and confirmed bookings together. Workspace revision checks ensure competing writes are reconsidered against the committed schedule.

03

Local opening hours need more than endpoints

The resource stores a recognized timezone and weekly local intervals. Validation checks that the requested duration remains in the supported same-day opening window and whole-minute precision. When elapsed and local minutes reveal a clock transition, interior minutes are checked too. This protects the tested fall-back case that endpoint comparisons alone would incorrectly accept.

04

Hold and booking states are separate

A hold records its expiry using server time and occupies capacity only while active and unexpired. Confirmation checks state, current record version and availability before creating the booking and linking the hold. Cancellation updates the appropriate record. Capacity checks ignore expired holds even without a browser running, so expiration does not rely on client-side timers.

05

Authenticated local records

Mutations use workspace-scoped records, session and CSRF checks, persisted operation identities and versions. Direct booking confirmation requires an owner. The application preserves cancellation state and provides a calendar representation of the saved appointment. It has no tested payment authorization or two-way calendar synchronization, so those external states must not be inferred from a local confirmation.

Operating the product

Start with the public interface to explore the design using example records. These interactions stay in the current view. Open the private workspace from the interface to use the existing account, storage and product workflows.

Maintain the resource timezone and opening hours deliberately. Inspect scheduled reservations before changing an operating assumption or blocked period.

On conflict, reload availability and choose a new interval. On expired hold, request a fresh hold; do not repeatedly confirm stale state.

Use cancellation to release a reservation and retain its history. Verify the saved booking status before communicating confirmation outside the app.

Before adding payment or external calendar connectors, define hold expiry versus payment timing, duplicate webhook handling, refunds, permissions and reconciliation as separate acceptance criteria.

Independent by construction

Cadence has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.

Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.

APPLY THE THINKING

A similar problem in your business?

Bring a real workflow, representative inputs and the result that needs to be reliable.

Shape a project brief