Sequential seat numbers,
no two attendees ever collide.
Every registration gets the next number in line. VIPs get V-1, V-2, V-3. General gets G-1, G-2, G-3. Assignment runs inside a DB transaction with row-level locks so two people submitting at the same instant never share a seat.
One transaction. One row lock. One seat.
Under load, the seat table becomes the bottleneck by design. That is exactly what prevents collisions.
Form to seat, in four database steps.
The race condition that got two aunties on the same chair.
A wedding reception in Delhi, 2024. The bride's family had reserved 40 seats in the front two rows for immediate relatives. We were using a rough seat counter that read the row count, incremented by 1, and wrote back. Worked fine for testing.
Actual event day: the bride's mother forwarded the RSVP link to the family WhatsApp group at 11.07am on a Sunday. Six aunties tapped the link within the same second. Three of them got seat number 12. When they showed up at the venue, one of them had to stand for the ceremony. We got yelled at in three languages.
Post-mortem was short. Increment-and-write is a textbook race condition. The fix is a database transaction with a row-level lock so concurrent registrations serialise. We wrapped seat assignment in `DB::transaction` with `lockForUpdate` on the same evening. Never happened again.
Small extra thing we added later: an audit log per seat, showing every attempted assignment and which one won. Makes debugging really easy when a client swears their VIP list is off by one.
A 250-seat awards night with 40 VIP seats.
- Setup, 3 minutes. Client creates the event with vip_seat_prefix=V, general_seat_prefix=G, max_vip_seats=40, max_general_seats=210. Registration opens.
- Registration flow. Attendee fills the form, hits submit. On the server, `DB::transaction` opens. `lockForUpdate` grabs the seat row for this event+category. Count = 6. New seat = V-7. Row committed. QR image queued for generation.
- Total latency. Registration form submit to confirmation page render: 400ms median, 900ms 95th percentile. Attendee never sees the lock happen.
- Concurrent load. A promo link posted to a 4,000-member Telegram group. In the first 60 seconds, 87 registrations arrive. Each waits for the lock, gets its seat, releases. No duplicates. VIP hits its 40-cap at second 34, remaining VIP requests get "VIP sold out" and are offered General instead.
- Cap reached. Once max_general_seats hits 210 (about 12 minutes later), the landing page auto-flips to Sold Out. Registration is closed at the model layer, not just the UI, so nobody can slip through by re-posting the form.
- Attendee experience. V-7 is printed on the branded pass. Same number appears on the badge printed at the kiosk. Same number in the concierge Excel export. One source of truth.
Zero shared seats across 12,000+ registrations we've run on this system.
Seat management tools compared honestly.
For a 500-seat ticketed event, one day, India 2026.
| Tool | Model / Cost | Notes | Verdict |
|---|---|---|---|
| BookMyShow venue tool | 10-12% ticket fee | Seat map picker. B2C-focused, hard to white-label. | Good for public shows |
| Cvent Session Seat Assignment | Enterprise add-on | Powerful. Sold in the base Cvent package (₹5L+ per year). | Overkill for most Indian MICE |
| Google Sheets + manual | Free + your Saturday | Works for 50 seats, breaks at 200. Duplicates guaranteed. | Zero until it isn't |
| SignupDesk seat allocator | Included | DB-level locking. Custom prefixes per event. Auto Sold Out. | Duplicate-proof by design |
Vendor prices vary by region and negotiated discount. Ours is included in the platform fee.