All case studies
Case study

Removing a webhook race condition with database-level idempotency

Replacing a check-then-insert on subscription webhooks with a UNIQUE constraint, so concurrent duplicate deliveries can no longer create duplicate transactions.

Context
Subscription payments via RevenueCat webhooks
Role
Backend
Key point
UNIQUE(transaction_id)
  • PostgreSQL
  • RevenueCat webhooks
  • Go / Node.js

The problem

Webhook providers can deliver the same event more than once.

The naive handler ran SELECT, then INSERT if nothing was found. Two concurrent deliveries could both see 'not found' and both insert.

Architecture: before → after

Before
  1. SELECT transaction_id
  2. Not found?
  3. INSERT (race between concurrent requests)
After
  1. INSERT
  2. UNIQUE(transaction_id)
  3. Duplicate → safely rejected

What I did

  • Added a UNIQUE constraint on transaction_id and let the insert itself decide.
  • A duplicate delivery now fails the constraint and is safely acknowledged instead of processed twice.

Outcome

  • Removed the race condition between concurrent webhook deliveries.
  • Simpler handler: the database is the single source of truth for idempotency.

More case studies

Talk about a similar problem