Stack guide
Queues between Stripe and your database: the durable middle
Writing webhook payloads directly to your database works until deploy windows, lock contention, or partial failures swallow exactly the events that mattered. The durable middle — verify, claim, publish to queue, acknowledge — survives all three while adding replay capability your future incident-self will thank you for. The pattern matters more than whichever queue product implements it.
Why direct-to-database fails quietly
Deploys drop in-flight handlers. Lock contention times out mid-transaction, rolling back claims while Stripe saw success. Partial failures persist half-parsed payloads. Each failure mode loses specific events silently — discovered weeks later as reconciliation gaps nobody can attribute.
The enqueue pattern
Verify signature → insert claim row (unique constraint on event id) → publish to durable queue → acknowledge. Claim rows deduplicate redeliveries; queue retention enables replay from webhook_events when downstream processing hiccups — self-healing infrastructure from two boring primitives.
Delayed delivery as race mitigation
Queue-level delayed dispatch (the five-second lesson generalised) serialises paired-event races deterministically under load, unlike handler sleeps that cold starts and timeouts corrupt. Delay inside durable infrastructure stays honest at scale.
Poison events and DLQs
Malformed or unexpectedly-shaped events retry forever without dead-letter handling. DLQs plus alerting convert poison from silent queue-clogging into visible anomalies worth investigating — occasionally they are signals of upstream schema changes arriving early.
Common questions
Which queue product?
Any durable one — managed (QStash, SQS) or self-hosted. The verify-claim-publish contract matters more than the brand.
Does this require a FeeGuard integration?
No — the page stands alone as stack guidance. FeeGuard observes your event stream externally rather than embedding in it.