Cha-ChingEvery e-commerce platform retries webhooks. Every one of them occasionally delivers the same event twice, concurrently, because the first delivery was slow rather than failed. If you have been running an integration for a while and have never seen it, you have seen it and not noticed.
What the check-then-insert does
The intuitive guard is to look first:
if (!(await findOrder(id))) await createOrder(...)
Two requests arrive four milliseconds apart. Both run the lookup. Both find nothing, because neither has inserted yet. Both insert. You now have two orders, two commission rows, and a call centre about to ring one customer twice.
This is not a thought experiment. A related system produced three duplicate finance records inside one second, in production, from exactly this shape.
The fix is a constraint
The only guard that holds is one the database enforces: a unique index on the platform order id, and an insert that expects to fail. Catch the violation, treat it as success, move on. The second webhook then becomes a no-op rather than a second order, and no amount of concurrency changes that — the database is the thing doing the arbitration, not your process.
Idempotency is a property, not a feature
The same reasoning covers the order form, where a customer with a slow connection taps Place order twice, and the intake API, where a client retries a request that actually succeeded. All three use the same mechanism, because all three have the same shape: the same operation, arriving more than once, must happen once.