Your outbox relay published twice. Is the outbox design broken?

Say it in 30 seconds

Say it like this (20-30 seconds)

A duplicate can be an expected recovery outcome. MiniTickets can publish to SNS and crash before the database transaction marks the row sent. The relay then retries the same saved event. Row locks prevent ordinary concurrent relays from taking the same row, but cannot make Postgres and SNS commit atomically. I would check the message and booking identifiers, then verify consumer outcomes rather than delete the pending event to hide the duplicate.

The deeper answer

The outbox promises that a committed booking retains an event to deliver. It does not promise one network publish. A lost SNS response can be ambiguous too: the relay sees a failure even if SNS accepted the request.

The relay uses stable identifiers from the stored payload and validates that they match its outbox row. Consumers should deduplicate the business operation. The email worker uses booking.confirmed plus the booking ID, rather than depending on the transport message ID. The ticket worker derives one ticket ID per booking seat.

For production, I would monitor publish failures, pending-row age and consumer completion separately. A growing outbox might mean a policy denial, topic misconfiguration or a database problem, not just harmless retries. Delivery is only useful when the downstream effect eventually happens, and the email consumer still has documented duplicate windows around its external send.

Counter-questions

Why keep row locks while calling SNS?

They stop another relay task from taking those rows during normal delivery. The cost is a connection and open transaction during network work; bounded calls and small batches limit that cost.

What if marking the row sent fails?

The transaction rolls back. The already accepted SNS event cannot be rolled back, so the row remains eligible for another publish and the consumer may see a duplicate.

Can a FIFO queue solve the whole problem?

It can add transport deduplication within its contract, but it does not atomically commit the database, email provider and queue. Business-level idempotency and explicit recovery are still needed.

Where in MiniTickets

Read Outbox, then inspect the outbox piece →.

apps/api/src/queries/outbox.ts → deliverBatch

Rehearse the consumer limit with the duplicate-email case.