Design a High-Spike Ticket Purchasing Platform

Context

A popular concert sale can trigger sudden spikes of up to millions of requests per second (RPS). You need to design a backend that:

• Prevents overselling.
• Ensures fairness among users.
• Remains resilient and observable under extreme load.

Assume: mobile-heavy traffic, a global audience, and both reserved seating and general admission are possible. Payments are processed through third-party gateways.

Requirements

1. Admission control at the edge (e.g., rate limiting, token bucket/leaky bucket).
2. Virtual waiting room and queueing model to smooth spikes and enforce fairness.
3. Anti-bot defenses.
4. Idempotent order creation and deduplication.
5. Inventory management: reservation-with-TTL vs immediate deduction.
6. Avoiding hot-spot keys under skewed access patterns.
7. Data model and partitioning strategy.
8. Caching strategy.
9. Consistency strategy (optimistic/pessimistic locking, outbox/inbox, retries).
10. Delivery semantics: exactly-once vs at-least-once.
11. Capacity estimates (QPS, p99 latency goals).
12. Failure handling (timeouts, circuit breakers, dead letters).
13. Monitoring and alerting.