The idempotency inventory — every duplicate-proofing trick in your code

Yesterday was the theory; today is the complete inventory, because "how do you avoid double-processing" is the #1 queue question, and your answer should be enumerative.

Zoth — event-driven, at-least-once, safe

1. Consumer dedup (the main line). PostgresDeduper.Seen (internal/queue/consumer/dedup.go): INSERT INTO processed_events(event_id) VALUES($1) ON CONFLICT DO NOTHING — if RowsAffected == 0, the event was seen. The key: <routingKey>:<event_id | id | request_id> — the routing-key prefix matters: the same request ID granted and revoked must not collide into one dedup entry. Body-SHA256 fallback when no ID field parses. Fail-closed: if the dedup check itself errors, the handler errors (retries, eventually DLQ) rather than risk double side effects.
2. Idempotent revoke. PlatformBridge.RevokeAccess treats zlink.ErrNotFound as success — "already gone, goal state achieved." So expire-then-manual-revoke, or revoke-then-expire, both converge.
3. Outbox relay claims. FOR UPDATE SKIP LOCKED — two relay replicas never publish the same batch (Day 62 full treatment).
4. Conditional state updates. UPDATE ... WHERE status=$expected — replayed approval events can't re-transition an already-ACTIVE request (loser gets ErrConflict).
5. Migrations under advisory lock — concurrent migrators serialize on pg_advisory_lock(72183921).
6. Group adds: ON CONFLICT DO NOTHING.

The residual gap you should be able to name: processed_events grows forever — needs TTL cleanup (a cron deleting rows older than, say, 30 days; dedup windows only need to cover redelivery horizons, not eternity).

Traverse — request-driven, multi-layer

1. Request-level: Submission @@unique([userId, idempotencyKey]) — extension retries return 200 + existing row, no double XP.
2. Solve uniqueness: @@unique([userId, problemId]) — the "was this a first solve?" answer is enforced by the DB, not by check-then-insert (which races).
3. Revision uniqueness: @@unique([solveId, revisionNumber, type]) — createNextRevision catches P2002 and returns the existing revision; initializeMLRevision early-returns if any ML revision exists; bulk import counts skippedExisting.
4. Problem upserts: @@unique([platform, slug]) — bulk import catches P2002 and re-reads the raced row (the correct pattern for find-or-create races).
5. Set-once semantics: updateMany({ where: { id, topic: null }, data: { topic } }) — AI classification can never overwrite a stored topic.
6. Notification delivery: @@unique([notificationId, channel]) at write time + FOR UPDATE SKIP LOCKED with a 120 s lease at send time + retry backoff min(60s·2^(n-1), 1h).
7. Broadcast fanout: jobId broadcast-fanout-<id> (BullMQ dedupes by job ID) + cursorUserId cursor making the job itself resumable — crash mid-fanout, re-enqueue, continue from the cursor.
8. Push drain: repeatable job with fixed jobId: 'notification-push-drain' — the scheduler can't stack multiple drains.
9. Ring closure: only updateMany({where:{closedAt:null}}) returning count === 1 emits the RINGS_CLOSED notification — the conditional update is the claim.
10. Bulk import in-batch dedup: normalize keyed by slug keeping the earliest happenedAt.

The taxonomy to recite

• Natural idempotency (state-setting writes): conditional updates, set-once.
• Deduplicated side effects (queues/webhooks): unique constraints, insert-on-conflict, job IDs.
• Goal-state convergence (external side effects): idempotent revoke.
• Claim-based single execution (workers): SKIP LOCKED / lease / conditional-update-as-claim.

The subtle point interviewers reward: the DB constraint is the last line, not the first. Application-level dedup (check-then-insert) races; constraints make duplicates impossible rather than unlikely. Both your codebases put constraints underneath every dedup decision.