Tech
Simple first
A simple solution, built on a few decisions with known trade-offs. As needs change, a decision may change with them, and only then is more complexity brought in.
Stack
- Front end
- Next.js, React, TypeScript
- Back end
- Python, FastAPI, Pydantic
- Database
- PostgreSQL
Decisions
One booking service and one database
- Why
- Every hold and sale is decided in one place, so nothing has to be kept in sync.
- Trade-off
- The database is both the scale limit and a single point of failure.
The database decides who gets a seat
- Why
- One judge for every seat, so two holds on the same seat cannot both succeed.
- Trade-off
- In a rush, every request waits its turn at the database.
A hold has an end time, not a clean-up job
- Why
- A seat counts as free once its hold's time is up; no scheduled job has to release it.
- Trade-off
- Expired holds stay stored until the showing is removed, and every seat check has to consider end times.
The seat map refreshes every 2 seconds
- Why
- Stateless, and works on any host.
- Trade-off
- Up to 2 seconds out of date, and each open map costs 60 ÷ 2 = 30 requests a minute.
Confirm stands in for payment
- Why
- Keeps the hold-then-confirm flow without a payment provider.
- Trade-off
- A real payment can outlast a hold; that case is not handled yet.
No accounts: each hold gets its own private link
- Why
- No sign-up, and no personal data to store or protect.
- Trade-off
- Whoever has that link can confirm or cancel the hold. Everyone else just sees the seats as taken.