
🎟️ Events, Ticketing & Creators · Deployment · Pro
Where a ticketing system runs to survive a big on-sale: waiting room at the CDN edge, autoscaled services, and databases sized for the spike.
Deployment diagrams are part of Pro. Anyone can view this one; generating and editing it needs Pro.
Drawing diagram…
Deployment for a high-demand ticket sale on AWS: Cloudflare runs the virtual waiting room and bot protection at the edge. Behind it an Application Load Balancer sends traffic to EKS, where catalogue, inventory and order services are pre-scaled before the on-sale. ElastiCache Redis holds seats; Aurora PostgreSQL with read replicas stores orders. SQS queues ticket delivery emails.
flowchart TB
FANS[Fans] --> CF[Cloudflare - waiting room and bot protection]
CF --> ALB[Application Load Balancer]
subgraph AWS[AWS Mumbai]
subgraph EKS[EKS - pre-scaled before on-sale]
CAT[Catalogue x10]
INV[Inventory x20]
ORD[Orders x20]
MAIL[Ticket Mailer]
end
REDIS[(ElastiCache Redis - seat holds)]
AUR[(Aurora PostgreSQL + read replicas)]
SQS[SQS - ticket emails]
end
ALB --> CAT
ALB --> INV
ALB --> ORD
INV --> REDIS
ORD --> AUR
CAT --> AUR
ORD --> SQS
SQS --> MAILA ticketing platform built for big on-sales: a virtual waiting room, seat holds, anti-bot checks, payments and mobile tickets with rotating QR codes.
How attendees get into an event quickly: QR scan at the gate, validity check that works even if the internet drops, and a live attendance count.
A platform where creators sell monthly memberships with exclusive posts, videos and community chat, and get paid out monthly.
How user posts on a social or creator platform are moderated: automatic checks, human review of doubtful content, and appeals.
Tables for an event platform: organisers, events, venues, ticket types, orders, tickets and check-ins.
The states of a ticket order, from seat hold through payment to use at the event, including refunds when an event is cancelled.