FindYourVibe

Problem — A limited-capacity event can be oversold if two people check out the last available ticket at the same moment — a naive read-then-write on the ticket count races, and a plain optimistic retry starts thrashing once a popular event's last few tickets get hit by a burst of checkouts.

Approach — Ticket rows are decremented inside a short transaction holding a pessimistic row lock, so the second buyer's write blocks for milliseconds behind the first instead of retrying blind — worth the small latency here because the alternative (optimistic compare-and-swap) means the losing buyer's client has to retry the whole checkout, not just a write. That decision reserves a slot in Redis with a TTL, so a buyer who abandons checkout releases the ticket back to inventory automatically instead of holding it hostage.

Problem — Explore and city pages filter a growing catalog of events by city, category, and date — a full scan gets slower as more events go live.

Approach — Compound indexes on city, category, and date back the explore and city pages, so filtering stays fast as the event catalog grows instead of degrading with it.

Problem — Payment webhooks can arrive more than once for the same order — retries, network blips — which would issue duplicate tickets if the handler just acted on every delivery, and doing ticket generation + email inline in the webhook handler makes the gateway wait on work it doesn't care about.

Approach — The webhook handler is idempotent, keyed on order ID, and its only job is to publish a "payment confirmed" event to RabbitMQ — a downstream consumer generates the ticket and sends the confirmation. A retried webhook delivery publishes once (the second is a no-op), and checkout stays correct under 300+ concurrent buyers on a single event drop without overselling a ticket.