Build Not yet confirmed elsewhere 1 publisher3 min readPublished Aug 22, 2026, 4:10 AM PDT

A unique index is not a duplicate check: the race inside a webhook idempotency middleware

A Node and Postgres webhook guide gets the storage choice right and the ordering wrong: SELECT then INSERT leaves a race that answers a concurrent duplicate with a 500.

The Engineer · Build desk

How we use AI Send a correction

What happened

A dev.to walkthrough argues that HMAC signature validation stops forgery but does nothing about a valid, signed payload being resent.
It keeps processed event IDs in a Postgres column with a UNIQUE constraint rather than Redis, on the grounds that a cache flush or restart loses the state.
The middleware rejects timestamps more than 300 seconds off, compares the HMAC with crypto.timingSafeEqual, then SELECTs the event_id and returns 409 if it is present.
The route handler inserts the processed_webhooks row first and runs the crediting logic afterwards.
The proposed test is one valid request, an immediate identical repeat expecting 409, and a ten-minute-old timestamp expecting 401.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

exposure Insert-first with no enclosing transaction marks an event done when the credit fails, and the 409 on every later attempt guarantees nobody retries the money that never moved.
cost Every honest delivery pays two round trips to settle a question the unique index settles inside the INSERT, and the SELECT buys nothing the constraint does not already enforce.
constraint The 300-second window caps how late a sender may retry: an attempt still carrying its originally signed timestamp is refused as stale, so an operator reads a lost event as a blocked attack.
contradiction The prose promises the event row is written inside the transaction block while the posted handler opens no transaction, so what a reader copies is the ordering without the guarantee.

The unique index in that schema is doing real work. The SELECT above it is not the thing doing it. Two deliveries of the same `event_id` arriving together both pass the 300-second freshness test, both pass the constant-time HMAC compare, both find no row, and both call `next()` ^[4]. Postgres then serialises them at the unique index and the second INSERT raises a violation ^[3], which the author describes as Postgres handling the lock and dropping the duplicate ^[14]. It does drop it, and the balance is not credited twice, because the INSERT sits above the business logic ^[5]. But the loser's exception falls into the handler's generic catch and comes back as HTTP 500 ^[5], and 500 is the status that tells a sender to come back. The 409 the design wants only shows up on a later attempt, once the winner's row is committed and visible to the lookup ^[4].

The case made for Postgres over Redis is durability: a cache flush or a container restart during a spike loses processed-event state ^[2]. That is a configuration argument, and configuration can answer it. The argument that tuning cannot answer is atomicity. When the dedupe key lives in the same database as the balance, one transaction makes the row and the credit succeed or fail as a unit. Two stores mean two commits and a gap between them, and everything that happens in that gap presents later as either a double credit or a payment that evaporated.

Two smaller things in the schema. A UNIQUE column is already backed by an index, so the explicit `idx_processed_webhooks_event_id` is a second index on the same column, and every inserted row pays for both ^[3]^[10]. And nothing prunes the table ^[8], although the freshness check quietly bounds what has to be kept: no request more than 300 seconds out of date reaches the lookup at all ^[4], so a row older than five minutes can never be matched by a duplicate that got through the first gate ^[12]. Five minutes of retention is sufficient for the mechanism as written, which is a much smaller storage commitment than an append-only ledger of every event you have ever seen.

The verification script in the piece is sequential: send, get 200, send the same payload again, get 409, then backdate the timestamp and get 401 ^[7]. That ordering is why the race survives testing. The second request always meets a committed row. Two curl processes started at the same moment would have produced the 500 instead, and the fix is in the same paragraph as the bug: let the INSERT be the check, and translate its failure into the conflict response the sender already knows how to read.

What to watch

Whether a revision handles the unique violation on the INSERT and answers 409 from it, which would let the SELECT go entirely.
Whether the sending platform re-signs each retry with a current timestamp; if it does not, the five-minute window will drop legitimate late deliveries.
Any retention job for processed_webhooks, and whether it prunes to the freshness window or keeps every event forever.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence58
Adoption: Insufficient
Hype gap+52
Incentives24
Confidence66

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
The dev.to writeup states that validating signatures is step one but will not protect against a replay attack in which a valid, signed payload gets resent.
ReportedSupportedView cited source
[2]
The author writes that processed event IDs could be stored in Redis, but a cache flush or a container restart during a high-traffic spike loses state, and recommends PostgreSQL with a unique constraint instead.
ReportedSupportedView cited source
[3]
The schema creates processed_webhooks with event_id VARCHAR(255) UNIQUE NOT NULL and then adds a separate index, idx_processed_webhooks_event_id, on processed_webhooks(event_id).
ReportedSupportedView cited source
[4]
The middleware runs three checks before execution: it rejects requests whose timestamp differs from now by more than MAX_AGE_SECONDS = 300 with a 401, compares an HMAC-SHA256 signature using crypto.timingSafeEqual and returns 403 on mismatch, then runs SELECT id FROM processed_webhooks WHERE event_id = $1 and returns 409 'Event already processed' if a row exists.
ReportedSupportedView cited source
[5]
In the route handler the INSERT into processed_webhooks runs before the business logic (a console.log crediting the user), and any thrown error is caught and answered with HTTP 500 'Processing error'.
ReportedSupportedView cited source
[6]
The article's prose instructs the reader to log the event inside Postgres as part of the transaction block, but the posted handler contains no BEGIN or COMMIT.
ReportedSupportedView cited source
[7]
The suggested local test is: a valid request returning 200 OK, an immediate identical repeat returning 409 Conflict, and an x-timestamp set ten minutes in the past returning 401.
ReportedSupportedView cited source
[8]
The processed_webhooks table has a created_at TIMESTAMPTZ defaulting to CURRENT_TIMESTAMP, and the article shows no pruning or retention policy for the table.
ReportedSupportedView cited source
[9]
With the INSERT committed before the business logic and no enclosing transaction, a failure in the business logic leaves the event recorded as processed and the effect never applied; every later delivery then matches the SELECT and is answered 409, so no retry repairs it. That is at-most-once, not exactly-once.
DerivedSupported1 source— create a free account to open them
[10]
A UNIQUE column constraint is backed by an index, so processed_webhooks carries two indexes on event_id and pays two index writes for every inserted row.
DerivedSupported1 source— create a free account to open them
[11]
Each accepted delivery costs two database round trips, one SELECT in the middleware and one INSERT in the handler, for a decision the unique index can adjudicate inside the INSERT alone.
DerivedSupported1 source— create a free account to open them
[12]
Since no request whose timestamp is more than 300 seconds from now reaches the database check, no duplicate that passes the freshness test can ever match a processed_webhooks row older than five minutes.
DerivedSupported1 source— create a free account to open them
[13]
A retry that carries the timestamp it was originally signed with and arrives more than five minutes later is answered 401 stale, before the event_id is ever looked up, so a lost delivery is reported as a blocked replay.
DerivedSupported1 source— create a free account to open them
[14]
The author states that if two identical requests hit the backend at the exact same millisecond, Postgres handles the lock and drops the duplicate.
ReportedContested2 sources— create a free account to open them View cited source
[15]
Because the duplicate check is a SELECT in middleware and the INSERT happens later in the handler, two concurrent deliveries of one event_id can both read no row and both proceed; the unique index rejects the second INSERT, and that exception is caught by the handler's generic catch and returned as 500 rather than 409.
DerivedContested2 sources— create a free account to open them

Sources

1 independent publisher whose own reporting we read for this story.

dev.to
1 article · August 22, 2026
How I Stop Webhook Replay Attacks in Node.js & PostgreSQL

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For a builder this is a paste-ready idempotency middleware with a specific structural defect worth internalizing: the duplicate check is a SELECT in middleware while the marker INSERT sits in the handler, so the unique index is doing enforcement while the SELECT is doing the deciding. The fix directions are visible from the published code itself: move the write into a single INSERT ... ON CONFLICT, distinguish the unique-violation error from generic failures instead of collapsing both to 500, and wrap the marker and the business effect in one transaction so the promised exactly-once actually holds. The redundant index on event_id and the second round trip are smaller but free wins.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence58: 0100
Verifiable code, no external corroboration
The source publishes the complete schema, middleware, and route handler, so the structural findings - SELECT in middleware versus INSERT in handler, missing BEGIN/COMMIT, duplicate index on event_id, catch-all 500 - are checkable directly against quoted code rather than inferred. What is absent is any independent testing, benchmark, or second publisher, and the claim that Postgres 'drops the duplicate' is asserted without a demonstration, so evidence is solid on structure and thin on behaviour under load.
AdoptionInsufficient: No adoption signal
The cluster contains one tutorial with no release, deployment, usage disclosure, benchmark, or incident data. Nothing indicates whether this pattern is running in any production system, so adoption cannot be scored without inventing facts.
Hype gap+52: −100 understated0 aligned+100 overstated
Exactly-once headline over at-most-once code
The framing promises that every webhook payload runs exactly once and that Postgres locks and drops simultaneous duplicates. The published code delivers neither: the read-then-write gap makes a concurrent duplicate surface as HTTP 500, and committing the marker before the business logic makes a post-marker failure permanent, which is at-most-once. The prose also claims a transaction block the code does not contain. The gap is real and specific, but bounded - the storage choice and the constant-time HMAC comparison are genuinely sound - so this is overstatement rather than fabrication.
Incentives24: 0100
Community tutorial, no commercial stake
The piece is a self-published first-person developer tutorial on a community platform, promoting no product, vendor, or paid service; the technologies named are open-source defaults. The visible incentive is authorial reach through a confident how-I-did-it framing, which plausibly explains the exactly-once headline outrunning the code, but there is no commercial or funding pressure evident in the material.
Confidence66: 0100
High on code reading, low on real-world behaviour
Confidence is high for everything derived from quoted code, because the artefact is fully reproduced and the reasoning about read-then-write races and unique-violation handling follows from it. It is lower overall because there is a single publisher, no adoption evidence, and no runtime observation, so statements about how often these paths fire in practice remain unresolved.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Database Concurrency and Read-Then-Write RacesFollow
Replay Attack DefenseFollow
Error Handling and HTTP Status SemanticsFollow
Postgres Schema and Index DesignFollow
Webhook Idempotency Follow