Kaiplan

The decision

A seating chart was one jsonb column per wedding, and every seat inside it held a guestId pointing at the normalized guest table: a foreign key Postgres could not see or enforce inside a JSON blob. A guest could also decline from the public wedding website without ever logging in, so the row that invalidated a seat could change from outside any session.

Four mechanisms enforced the invariant the schema could not express: a zod refinement blocking a chart that seated the same guest twice, a transactional re-read on save that rejected a stale reference, a self-repairing read that dropped assignments for guests who had since declined or been deleted, and seven call sites that stripped a guest out of the chart in the same transaction that removed them.

The call site that mattered was the seventh: the public RSVP handler, reachable with no session at all, behind a rate limiter and a Turnstile check. That route lived inside apps/api/src/routes/wedding-website.ts, 1,559 lines carrying most of the guest-facing surface, and it sat outside the per-file coverage gate: the highest-risk call site and the thinnest test evidence sat in the same file.

Architecture

Three Cloudflare Workers sat in front of two databases and one Durable Object: a React SPA for the couple, an Astro site for guests and marketing, and a Hono API between them. Postgres, behind Hyperdrive with a pool capped at one connection, held the transactional product data: weddings, guests, budgets, vendors, seating charts.

A separate Cloudflare D1 instance held marketing signups, pricing clicks, and email preferences, bound into both the product API Worker and the marketing Worker, so a transactional product email could honor an unsubscribe made from a marketing footer without either Worker touching the other’s primary store.

Stripe webhook verification ran through Stripe.createSubtleCryptoProvider(), since the Workers runtime has no Node crypto module to verify signatures the usual way. Five nightly maintenance jobs, scheduled through Cron Triggers, ran strictly in series to match Hyperdrive’s single-connection pool, each job holding that one connection until it finished before the next began.