Ventora Sequencer

The decision

The send path was defended four times over, because Cloudflare guarantees a Durable Object alarm fires at least once, not exactly once. An alarm handler that crashes after sending an email but before recording that it sent is simply retried, with no memory of the first attempt. Every other failure in this system was recoverable; a duplicate email to a stranger was not.

Each layer assumed the others would eventually be wrong. The Durable Object refused to re-enter a step already marked sent. A crash between writing the message and writing the step was repaired by looking for the orphaned message rather than guessing which way to resolve it.

Two unique database indexes made a duplicate message physically unrepresentable, one step to one message by constraint rather than convention. If all three failed anyway, the outbound call to Resend still carried an idempotency key derived from the run and step, so an identical retry produced an identical key the provider would collapse on its own.

Architecture

Everything ran on one Cloudflare Worker: the product API, the operator dashboard’s static assets, the provider webhook endpoints, a queue consumer, four cron jobs, and one Durable Object per enrollment whose alarm() handler was the state machine driving that person through their sequence.

Three authentication regimes coexisted on that single Worker, decided by URL prefix. The product API and the operator dashboard both delegated authentication entirely to Cloudflare Access (service tokens for the former, Google IdP plus an email allowlist for the latter), so there was no login form, session, or password anywhere in the application code. Provider webhooks and the one-click unsubscribe link verified themselves instead, with HMAC signatures the Worker checked directly.