Retry-safe webhook ingestion with PostgreSQL: duplicates, concurrent requests and old snapshots

Thu, 15 Oct 2026 12:15:00 +0000

This is a synthetic laboratory example, not a customer production incident. AI assisted with drafting and checking the material.

A webhook sender cannot always tell whether a delivery worked. The receiver may commit a database transaction and lose the connection before returning a response. A retry then arrives for work that is already complete.

Event IDs address that ambiguity, but they do not solve ordering. Two different events can describe the same object, and the older event can arrive last. A receiver that blindly replaces the stored state can move an order from a newer revision back to an older one.

PostgreSQL as a Workflow Engine: Building Reliable Long-Running AI Jobs Without Kafka

Wed, 16 Sep 2026 11:00:00 +0000

Every document-processing system I have worked on arrives at the same shape. Something uploads a file, something else has to read it, run it through an extraction or inference step that takes seconds to minutes, and store a result. The work is slow, it fails sometimes, and the answer has to be auditable afterwards.

The default advice is to put a message broker in front of it. That advice is not wrong, but it is usually given before anyone has measured whether the database already sitting in the stack can do the job. So I built the thing and measured it: a job queue inside PostgreSQL, four different claim strategies, workers scaled from 1 to 16, a worker killed mid-job on purpose, and query plans checked against a queue table buried under half a million completed rows.

Concurrency on Percona Community

Retry-safe webhook ingestion with PostgreSQL: duplicates, concurrent requests and old snapshots

PostgreSQL as a Workflow Engine: Building Reliable Long-Running AI Jobs Without Kafka