🎫
Marketplace & Booking

Concert Ticket Booking

Flash Traffic Aur Seat Locking
💡 Concert booking SAAL MEIN EK BAAR khulne wala darwaza hai jiske peeche 10 lakh log khade hain. Baaki din system khaali baitha rehta hai — design us EK MINUTE ke liye hota hai.

Ye problem EXTREME BURST ke baare mein hai. Normal load 100 QPS, ticket drop par 5 lakh QPS. Isliye do cheezein zaroori hain: VIRTUAL WAITING ROOM (users ko queue mein rakho aur controlled rate se andar bhejo) aur seat inventory ko Redis mein rakhna, DB par nahi.

Seat locking ka wahi principle hai jo LLD mein hai par distributed scale par — Redis mein TTL lock (SET NX EX 600). Payment success par DB mein durable booking likho. Aur OVERSELL ko har haal mein roko: seat claim atomic Lua script se, kyunki yahan double-sell reputational disaster hai.

// Virtual waiting room — burst ko flatten karta hai
User → Waiting Room (queue position + token)
     → controlled rate (jaise 1000/sec) se Booking Service mein
     → Redis: atomic seat claim (SET NX EX)
     → payment → durable booking (DB)

// Redis down hone par? Booking band karo, oversell se behtar hai.
🎫
Concert booking SAAL MEIN EK BAAR khulne wala darwaza hai jiske peeche 10 lakh log khade hain. Baaki din system khaali baitha rehta hai — design us EK MINUTE ke liye hota hai.
1 / 2
⚡ Quick Recap
  • Design normal load ke liye nahi, burst ke liye hota hai
  • Virtual waiting room se traffic flatten karo
  • Seat claim atomic (Lua) — oversell kabhi acceptable nahi
Is page mein (2 subtopics)

Ticket drop se pehle users ko waiting room mein rok liya jaata hai. Har user ko ek queue position aur token milta hai. System controlled rate se (jaise 1000/sec) tokens ko "active" karta hai aur unhe hi booking page tak pahunchne deta hai.

Ye backend ko flat, predictable load deta hai. Bina iske 5 lakh QPS ka spike aata hai aur sab kuch girta hai. Aur user experience bhi behtar hai — "aap 4,312 number par hain, 3 minute" random error se kahin acchha hai.

// Waiting room ka core — Redis sorted set
ZADD waitroom:concert_99 <timestamp> <userId>   // enter
ZRANK waitroom:concert_99 <userId>              // position

// Har second top N ko token do, wahi booking service tak jaate hain

Ticketing mein oversell reputational disaster hai — refund se maamla theek nahi hota. Isliye seat claim atomic honi chahiye aur inventory ka SINGLE source of truth hona chahiye.

Redis mein atomic Lua script se claim karo. Redis unavailable ho to booking BAND kar do — "kuch der baad koshish karein" dikhana, do logon ko ek seat bechne se hazaar guna behtar hai. Failure mode explicitly choose karna zaroori hai.

💡Tip: "Redis down ho gaya to?" ka jawab "DB par fallback kar lenge" mat dena — do sources of truth se oversell hota hai. Sahi jawab hai "booking rok denge". Availability se correctness chunna yahan sahi call hai.