Definition
An advisory lock is a database-level mechanism that prevents two processes from modifying the same data simultaneously. In ticketing, this prevents scenarios like two people buying the last ticket at the same moment.
Why Ticketing Needs This
Imagine 50 tickets remaining and 60 people click Buy at the same time. Without locking, multiple checkouts could read 50 available and all proceed — resulting in 60 tickets sold for 50 places.
Advisory locks ensure only one checkout at a time can modify the inventory count. The first 50 proceed, the rest see sold out. No overselling, no disappointed fans.
Where Tickts Uses Locks
- Inventory — preventing overselling during checkout
- Ticket scanning — preventing double-scan at the gate
- Promo codes — preventing promo usage exceeding the limit
- Refunds — preventing double-refund processing
- Transfers — preventing conflicts during ticket transfer
- Payment plans — preventing duplicate instalment charges
Advisory Locks in Plain English
An advisory lock is a coordination mechanism used in database systems to prevent two processes from doing the same thing at the same time. In the context of event ticketing, advisory locks prevent problems like selling more tickets than available, processing the same refund twice, or applying the same promo code beyond its usage limit.
Think of it like a changing room in a shop. The lock on the door is advisory — it does not physically prevent someone from entering, but everyone agrees to check the lock before opening the door. In database terms, every process checks for the lock before proceeding with a critical operation.
Why Ticketing Needs Advisory Locks
Consider this scenario: 100 fans try to buy the last ticket at the same time. Without a lock, all 100 requests might check availability, see one ticket remaining, and all proceed to create an order. Result: 100 orders for 1 ticket — a disaster.
With an advisory lock, the first request acquires the lock, checks availability, creates the order, and releases the lock. The second request then acquires the lock, checks availability, finds zero tickets remaining, and rejects the purchase. Clean, safe, and fair.
Where Tickts Uses Advisory Locks
- Checkout: When a fan completes their purchase, a lock prevents other transactions from simultaneously modifying the same ticket inventory.
- Refunds: Processing a refund acquires a lock to prevent the same refund from being processed twice (e.g., if an organiser accidentally clicks the refund button twice).
- Promo codes: Applying a promo code checks and updates the usage count within a lock, preventing the code from being used beyond its limit.
- Ticket transfers: Transferring a ticket locks the operation to prevent the same ticket from being transferred to two different people simultaneously.
- Webhook processing: Payment webhooks from Stripe are locked to prevent duplicate processing if Stripe retries a webhook delivery.
The Technical Implementation
Tickts uses MySQL GET_LOCK and RELEASE_LOCK functions for advisory locking. These are lightweight, efficient, and do not block normal database queries. The lock is identified by a unique string (e.g., "checkout_order_12345") and has a timeout to prevent deadlocks if a process crashes while holding a lock.
Frequently Asked Questions
Do advisory locks slow down the system?
No. Advisory locks are extremely fast — acquiring and releasing a lock takes microseconds. The operations they protect (inventory checks, refund processing) take milliseconds. Fans experience no noticeable delay.
What happens if a lock gets stuck?
Every lock has a timeout. If a process crashes while holding a lock, the lock is automatically released after the timeout period (typically a few seconds). This prevents permanent deadlocks.
Can I see advisory locks as an organiser?
No, and you do not need to. Advisory locks operate entirely behind the scenes. As an organiser, you simply experience correct, reliable behaviour — accurate inventory, single-processed refunds, and fair promo code enforcement.
