eBay System Design: Concert Ticketing with Real-Time

Overview

You are asked to redesign a high-demand concert ticketing backend (e.g., for Taylor Swift–level launches) so users see accurate seat availability in real time and tickets cannot be oversold. The system must support millions of concurrent users, short reservation windows, fast read responses (<100ms), and social features (showing friends' purchases) without adding significant latency.

What you'll be asked to design

You should propose a read/write-separated architecture where a durable write store is the source of truth and low-latency read stores provide availability checks. Explain how reservations with TTLs, idempotency keys for checkout, and optimistic/strong concurrency controls prevent oversells. Discuss cache consistency strategies (write-through, cache-aside with versioning, or invalidate-on-write) and how to minimize replication lag (CDC streams like Kafka to push updates to read replicas or materialized views).

High-level flow and stages

1. Client requests availability -> edge cache / regional read replica returns seat map (<100ms).
2. User reserves seat -> short TTL reserve entry in Redis and a write to the primary store (transactional).
3. Checkout -> payment processed with idempotency; final write marks seat sold; CDC updates read projections and invalidates caches.
4. Notifications sent asynchronously (email/SMS).

Key skills & signals to demonstrate

Show knowledge of distributed systems (replication, CDC), caching and cache-consistency techniques, concurrency control (optimistic locking, distributed locks like Redis carefully), rate limiting and anti-bot strategies, capacity planning for spikes, fault tolerance, and secure payment handling. Describe trade-offs (latency vs. consistency) and deployment patterns (multi-region read replicas, autoscaling, observability).