Ticket Booking diagram template
Prevent double booking with seat holds, a waiting room and transactional payments.
About this design
Selling a limited set of seats to a huge crowd is a concurrency problem wearing a retail costume. The core rule is that a seat can be held by exactly one person at a time, so selecting a seat creates a short-lived hold with an expiry, stored in Redis for speed and mirrored by a transactional database that is the final authority. A virtual waiting room in front of the booking service meters entry when a popular event opens, protecting the backend from a stampede. Checkout converts a hold into a booking inside a database transaction and only then charges the payment provider, with idempotency keys so a retry never double charges. Expired holds return seats to the pool. Use this template to compare pessimistic and optimistic locking, discuss bot defence, and plan what the user sees when a hold times out during payment.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Ticket booking"
direction LR
user "Buyers" -> service waitroom "Waiting room" -> gateway "API gateway" -> service book "Booking service"
book -> cache redis "Seat holds"
book -> db postgres "Bookings"
book -> external stripe "Payment provider"
book -> queue sqs "Confirmation queue" -> worker mail "Email confirmations"
