
Outbox relay lease expiry without breaking delivery invariants
A new lease‑and‑fencing‑token design lets an outbox relay expire without violating the guarantee that every committed event is offered at least once, even when duplicate broker messages occur.
Relay systems must enforce bounded ownership and maintain delivery guarantees across a database and message broker without a shared transaction. The contract: every committed outbox event is eventually offered at least once, and consumers must tolerate duplicate offers without breaking business invariants [devto].
What shipped
The implementation introduces a lease that limits concurrent ownership and a fencing token that increments on each claim. When a relay instance finishes, it presents the token; a newer lease with a higher token can reject stale completions, preventing a stale instance from marking a newer lease as complete. The token is stored alongside the lease, enabling atomic check‑and‑set semantics without extra coordination [devto]. The token does not retract messages already published by the stale instance.
Why it matters
Lease expiry after a send operation is the only point where duplicate broker messages can appear. By coupling lease expiry with fencing tokens, the system blocks stale completions while still allowing the broker to retain messages until the consumer acknowledges them. Consumer inboxes must retain deduplication records for at least the maximum redelivery window; deleting records after one day while a dead‑letter queue holds messages for a week can re‑introduce old effects [devto]. This design forces engineers to balance bounded ownership, crash recovery, and post‑send ambiguity, ensuring exactly‑once delivery semantics despite the lack of a shared transaction.
Subscribe to the broadcast.
Daily digest of the day's most important tech news. No fluff. Engineering signal only.
// delivered via substack · double-opt-in confirmation


