How would you expand bookings across regions without selling the same seat twice?

Say it in 30 seconds

Say it like this (20-30 seconds)

This is an explain-only extension; MiniTickets has one regional Postgres authority. I would start with a single write region and distribute reads, then define recovery-point and recovery-time objectives. Concurrent writes in multiple regions require an inventory ownership or coordination model; asynchronous replication alone cannot prevent overselling during a partition. Routing users elsewhere is insufficient unless the new writer has safe ownership and the previous writer is fenced from accepting more bookings.

The deeper answer

The current row lock serializes bookings inside one database. Copying its state asynchronously to another region does not extend that lock across two independent writers. Both can see the same remaining capacity and accept incompatible bookings.

One proposed option assigns each event a home write region. Another partitions explicit inventory allocations among regions, accepting that unsold capacity may remain elsewhere during a partition. A globally coordinated write system has different latency and availability costs. Choose from product requirements and failure tolerance, not a requirement to use every region for writes.

For failover, define acceptable data loss, promote only after establishing writer ownership, and prevent the previous writer from returning unnoticed. Idempotency keys and queued side effects also need a regional recovery story; replicated data and replayed jobs can produce duplicate business actions. None of the cross-region replication, fencing, routing or recovery automation is implemented here.

Counter-questions

Could DNS failover solve database consistency?

It routes requests; it does not revoke the old writer or reconcile concurrent inventory decisions.

What if zero data loss is mandatory?

That requirement constrains replication and acknowledgment strategy and can increase latency or reduce availability during a partition. Agree on it before selecting technology.

Why keep one write region initially?

It preserves the existing transaction model and lowers operational complexity. The trade-off is write latency and regional recovery exposure.

Where in MiniTickets

Read the path chapter, select the relevant map piece →, then inspect apps/api/src/queries/bookings.ts → createBookingTx.