How we built an event ticketing platform for 500+ events and 120K tickets sold — with scalable checkout, fraud prevention, refund workflows, and 99.5% availability accuracy.
Checkout · Fraud Prevention · Multi-Venue
An events company running concerts, conferences, and festivals across multiple venues was losing sales to double-bookings and slow checkout. Popular events would sell out in minutes — their legacy system couldn't handle concurrent purchases. Customers complained about over-sold seats and refund delays.
They wanted a ticketing platform that could handle flash sales, prevent overselling with real-time inventory locks, detect fraud, and support refund workflows — plus multi-venue seat maps and tiered pricing.
During flash sales, thousands of users added tickets to cart simultaneously. The old system reserved inventory at add-to-cart but didn't handle race conditions. Overselling was common.
Bots and scalpers were buying tickets in bulk. Chargebacks and disputed transactions cost the business. No velocity checks or device fingerprinting — fraud went undetected until after the fact.
Refund requests were manually processed via email. No self-service portal. Cancelled events required batch refunds — the old system couldn't handle thousands of refunds at once.
Different venues had different seat maps — some general admission, others reserved. The old system assumed a single venue model. Supporting multiple layouts and pricing tiers required custom code per event.
We built a ticketing platform with Redis-based inventory locking, Stripe for payments, and Twilio for SMS confirmations. Inventory is reserved with time-limited locks (e.g., 10 minutes) at add-to-cart. Fraud detection uses velocity rules and Stripe Radar. Refund workflows are automated with configurable policies.
Inventory locking was the critical piece. We use Redis Lua scripts for atomic reserve-and-lock. When a user adds tickets, we decrement available count and set an expiration. If they complete purchase, we confirm the allocation. If they abandon or expire, we release. Under load, Lua ensures no race conditions.
Mapped event and venue workflows. Designed seat map and ticket tier models. Defined inventory locking strategy and Redis key structure.
Built event catalog and seat map selector. Implemented Redis-based inventory locks with Lua scripts. Integrated Stripe Checkout. Developed order confirmation and ticket delivery flow.
Configured Stripe Radar rules. Built velocity and device checks. Implemented refund workflow with policy engine. Added Twilio SMS for confirmations.
Extended seat maps for multiple venue types. Load-tested with simulated flash sale (5K concurrent users). Phased rollout — 50 events first, then full catalog.
Ticketing inventory is a classic concurrent access problem. Redis with Lua scripts gave us atomic operations — reserve, confirm, release. Lock expiry (e.g., 10 minutes) is critical; too short and users lose their selection mid-checkout, too long and inventory is stranded. We tune per event type.
Stripe Radar plus custom velocity rules caught most fraud. We added device fingerprinting and blocked high-risk patterns (many cards, same IP). The tradeoff is false positives — some legitimate buyers get blocked. We built an override flow for support to manually approve.
Multi-venue support required an abstract seat map model. We defined zones (GA vs reserved), tiers (VIP, standard), and capacity per zone. Each venue maps to this model. General admission is a single zone with capacity; reserved seating uses a grid. The checkout UI adapts to the map type.
We help events and e-commerce companies build production-grade ticketing systems. Let's talk about your architecture.