Oversell lock
The reservation function was rewritten with an event-level advisory lock, row-level locking and a conditional "remaining ≥ requested" update. Seat conflicts roll the counter back automatically. Verified under load testing.
Ticketing
Biletime
A ticketing platform for concerts, festivals and theatre: a race-proof capacity lock, edge bot protection, QR tickets and AI-assisted seating. 99k lines of code, 71 tables.
Technical profile
What it is built with
| Stack | React 18 + TypeScript, Vite, Tailwind CSS, TanStack Query |
|---|---|
| Backend | PostgreSQL with edge functions, rate limiting and bot protection at the edge |
| Codebase | ~99,000 lines · 667 files |
| Interface | 215 components · 42 admin + 22 organiser screens |
| Database | 71 tables · 112 versioned migrations |
| Server functions | 35 (payments, notifications, payouts, auto pricing, webhooks) |
| Mobile app | Android — com.biletime.app |
| Tickets | QR generation, email delivery, single-use validation at the door |
| Testing | End-to-end suite — 20/20 passing |
What makes it different
Not a standard website
- Capacity survives a race. Reservation uses an event-level advisory lock, a row lock and a conditional "remaining ≥ requested" update. A standard site reads then writes — and sells the same ticket twice under concurrency.
- Built for traffic spikes. Rate limiting and bot protection run at the edge before requests reach the database; hot queries are indexed and cached. Target capacity is a million-user scale.
- Tickets are digital and single-use. A QR is burned on validation, so a screenshotted ticket will not pass twice.
- AI sits next to the organiser. Drafting event copy, extracting a seating layout from an image and designing venue plans are built into the system.
- Money flow is in the system too. Organiser payouts, overdue alerts and venue requests have their own screens — most ticketing sites fall back to spreadsheets here.
- It emits events to external systems. Sales and cancellations can be delivered to the organiser's own stack over webhooks.
What we did
The solution in six parts
Scaling work
An edge layer, rate limiting, bot protection and image delivery were introduced; hot queries were indexed and cached. Target capacity was raised to a million-user scale.
Digital tickets and door control
QR tickets generated after purchase, delivered by email and validated once at the door, with a live sales and remaining-capacity dashboard for organisers.
AI-assisted organiser tools
Assistants that draft event descriptions, extract a seating layout from an image and design venue plans, plus waiting-list and follower notifications.
Payouts and operations
Organiser payout tracking, overdue payout alerts, venue requests and webhook delivery of events to external systems.
Independence and testing
The platform was fully separated from its external development environment: authentication, database and file storage moved to our own infrastructure, with an end-to-end test suite and full type safety.
Components
What was built
- 29 pages and 70+ components, including 42 admin and 22 organiser screens
- Capacity reservation using an advisory lock, row lock and conditional update
- Rate limiting and bot protection at the edge on a key-value store
- Email queue with delivery state tracking and unsubscribe handling
- Separate server functions for automatic pricing and webhook dispatch
- End-to-end test suite, 20/20 passing
- Image resizing and delivery layer
- Mobile app package and store release
Other projects
Take a look at these
Want a similar system?
Most of the problems we solved on Biletime repeat across sectors. Tell us about yours and we will scope it together.