Can you guarantee exactly one confirmation email per booking?

Say it in 30 seconds

Say it like this (20-30 seconds)

The current implementation cannot guarantee exactly one email. It checks a durable booking-based completion record, sends through the mailer, then records success. That suppresses ordinary later duplicates, but a crash after send or concurrent workers can send twice. Recording success first would risk losing the email. I would state the at-least-once trade-off and, if the requirement were stricter, look for a provider-supported idempotency contract and reconciliation rather than promise exactly-once delivery.

The deeper answer

The email job key identifies the business effect: booking.confirmed for one booking. DynamoDB reads are strongly consistent, and the completion write is conditional. Those details stop stale completion reads and conflicting writes; they do not reserve the job before sending.

Two workers can both read no completion record, both send, and then race to record completion. Only one record is created, but two external effects may already have happened. A single worker can also send successfully and fail before saving completion.

Records carry a thirty-day TTL for eventual cleanup, so duplicate suppression is not permanent history. A manual replay after the record disappears can send again. A lease could reduce simultaneous sends, but a crashed sender with an uncertain provider outcome still needs a policy. Also distinguish provider acceptance from actual inbox delivery: neither this record nor a successful API call proves receipt.

Counter-questions

Why not mark completion before sending?

A crash after that write but before the email call would make future retries skip an email never sent. The present choice prefers possible duplicates to that loss window.

Would a conditional put after send stop the race?

It stops duplicate completion records. It happens too late to stop two workers from having already sent their emails.

What would you promise the product team?

Durable retries and best-effort suppression within retained history, with known duplicate windows. A stricter contract needs explicit provider capabilities, outcome reconciliation and a decision about ambiguous sends.

Where in MiniTickets

Read Dynamodb, then inspect the processed-jobs-table piece →.

apps/worker/src/handlers/booking-confirmed.ts → handleBookingConfirmed

Compare the duplicate-email case.