A ticket worker crashes halfway through a four-ticket booking. How does retry recover?

Say it in 30 seconds

Say it like this (20-30 seconds)

MiniTickets gives every seat a stable booking-derived ticket ID, reserves its canonical record, writes the PNG and then marks it ready. A retry skips ready tickets and resumes creating ones, writing the same object key and token. That makes partial progress recoverable without minting extra seats. It is still a multi-store workflow, so the creating state and queue retries are essential; an unavailable dependency can leave a confirmed booking temporarily without usable ticket images.

The deeper answer

For seat one through quantity, the handler derives ticketId from booking ID and seat number. DynamoDB conditionally creates that owner’s ticket record. A competing delivery reads the existing record strongly and uses its stored token. It rejects a changed booking identity rather than silently replacing another record.

If the process stops after reservation, the retry writes the image. If it stops after S3 accepts but before ready is saved, the retry overwrites the same object and marks the record ready. Existing ready records skip S3 entirely. This is a recoverable state machine: each durable state says which work remains.

The API keeps Postgres as booking truth and returns bookings even if asynchronous ticket records are missing. It exposes only validated ready tickets. Production hardening could add reconciliation for old creating records or accidentally deleted objects; the current ready flag alone does not continuously prove that the S3 object still exists.

Counter-questions

What if two workers generate the same seat?

The conditional reservation chooses one canonical record. The loser uses that stored token, so concurrent deliveries may repeat a write but do not choose different ticket identities.

Does a missing QR cancel the booking?

No. The seat purchase committed separately in Postgres. The API can show creating until all expected ready tickets exist, while operations repair the failed asynchronous path.

Why not save ready before writing S3?

A crash would expose a ready record for an image that was never stored. Writing the image first allows a safe retry if the later status update fails.

Where in MiniTickets

Read Lambda worker, then inspect the tickets-table piece →.

apps/worker/src/handlers/tickets.ts → handleTickets