Idempotent Consumers

Make the business effect safe to repeat#

{ eventId: "evt_123", orderId: "order_42", type: "OrderPaid" }

A consumer can record the event ID, enforce a business-level unique constraint, or use an idempotency key. The dedupe record and side effect need one atomic boundary where possible; a naïve read-then-write check races under concurrent delivery.

BEGIN
INSERT processed_events(event_id) VALUES ('evt_123')
  -- unique constraint rejects duplicates
INSERT receipt_jobs(order_id) VALUES ('order_42')
COMMIT

Retention must cover the redelivery/replay window without growing forever. See the later Idempotency lesson for the full reliability treatment.