How do you make a booking retry safe across API instances?

Say it in 30 seconds

Say it like this (20-30 seconds)

The browser sends one UUID for one booking intent and preserves it across retries. MiniTickets stores that key on the booking with a unique constraint on user and key. The seat change and booking commit together, so another API task can return the same booking. The service rejects a reused key with different event or quantity. This protects successful retries without relying on process memory or an expiring Redis entry.

The deeper answer

A pre-check alone is insufficient: two requests can both observe no previous booking. The unique database constraint settles that race. For two events using the same user and key, one transaction can lose its insert after decrementing seats; the entire losing transaction rolls back, then the query reads the winner’s booking.

The service compares the stored event and quantity with the new input. Matching parameters replay the public booking; different parameters yield a conflict. Existing successes remain replayable even after the event sells out or starts.

This implementation stores successful bookings rather than every HTTP response. A rejected booking writes no success row, so the same key may try again later. I would document that contract explicitly for clients. Keys do not expire in this schema, which simplifies correctness at the cost of retaining them with every booking.

Counter-questions

Why scope the key to the user?

One user’s key must not reveal or replay another user’s booking. Ownership comes from the authenticated session, and the unique constraint includes user_id.

What if the two requests arrive simultaneously?

The event lock handles same-event contention. The unique constraint also handles different-event reuse; the loser rolls back before reading the committed winner.

Would a Redis SET NX be enough?

It would not atomically commit with the booking in Postgres. A crash between stores could permit a duplicate or leave a false completed marker; the database row avoids that extra protocol.

Where in MiniTickets

Read Idempotency, then inspect the rds-postgres piece →.

apps/api/src/services/bookings.ts → bookTicket