The atomic reserve pattern
Check-and-hold as a single serialised operation — the same spine for any booking, ticketing or inventory system where two buyers cannot win the same thing.
Angel Wings
A demonstration storefront for wing hire and purchase, with date selection, a basket and an owner view.
- Stack
- React 19 · tRPC · Hono · Durable Objects
- Deploy
- GitHub Actions → Cloudflare Worker
- Inventory
- 2 products · hire + purchase + packages
- Money
- Demo — payment collection disabled
- Ledger
- Single-writer Durable Object
- Gates
- typecheck · lint · tests · build · post-deploy curl
01 The brief
The demo explores a small wing-hire catalogue, with hire dates, purchase options and limited inventory.
Payment collection is disabled in this demonstration. It shows a booking and order flow, with simulated payment confirmation.
02 What was built
Date-based hire and limited inventory.
- Editorial storefront: catalogue, hire vs buy, packages with add-on rules
- Live date availability checked against every existing hold as you type
- Hire durations (3-night / week) with derived return dates
- Packages combining wings, makeup and photography with per-package add-ons
- Atomic reservation — availability check and hold are one operation, not two
- Server-authoritative pricing from the same data the pages read
- Order ledger with idempotent checkout — double-clicks produce one order
- Studio admin view: hire diary, order counts, enquiries
- Payment collection disabled for the demo
03 The system
The website is the surface. This is the path underneath.
Step 1 — Browse
Two products, photographed like couture — because two products photographed properly outsell forty photographed badly.
04 Behind the screen
Backend decisions you'll never see, and always feel.
- 01
Why not a normal database row?
The first prototype stored holds in a key-value store; a measured delay of about a minute before a new hold became visible meant a real double-booking window. So the reservation moved into a single Durable Object that serialises every check-and-write. Slow infrastructure was replaced by correct architecture.
- 02
Atomic means atomic
The reservation flow uses an atomic section for hold checks and writes. Overlap and retry scenarios need acceptance testing before a live launch.
- 03
One codebase, two runtimes
The commerce engine runs on Node in development and on Cloudflare Workers for the deployed demo, with a storage adapter for each runtime.
- 04
Prices are data, not copy
Two data modules are the single source of truth for the pages and the order builder alike. Hard-coded dollar figures are forbidden by the repo’s own working rules.
- 05
The demo payment boundary
Payment collection remains disabled. This example shows the user journey and does not establish a history of paid customer orders.
05 Project screenshots
Real screenshots, no mockups.
Demo build — payment collection is disabled
View demo storefront angel-wings-demo.mysticwellnesssydney.workers.dev
06 What became reusable
Your build can reuse patterns from this project.
Holds as sortable keys
Date ranges encoded so overlap is a string comparison. Tiny, portable, and testable without any infrastructure.
Idempotency at two levels
Fast replay before the work, authoritative check inside the atomic section. Double-clicks and retries collapse into one order.
Payment activation
A live payment connection, provider configuration and production acceptance checks are separate launch work.
· Next case study — 01
Mystic Wellness
A wellness studio that used to book by text message now runs sessions, studio hire, workshops, a shop, gift cards and referrals through one system.