We use cookies for site analytics. Accept to help us understand how the site is used. See our Privacy Policy for details.
Ten million buyers, five hundred thousand tickets, one contended counter. Virtual waiting rooms, TTL reservations, idempotent payments, and the oversell-vs-throughput dial.
Design the system behind a high-demand on-sale: a concert with 500,000 tickets goes on sale at 10:00 AM and 10 million people are refreshing at 9:59. Buyers browse seats, hold a selection for a few minutes while they pay, and either complete the purchase or release the hold. The same shape appears as a flash sale (limited-stock product drop), sneaker release, or course registration.
The defining property: demand exceeds supply by 20x and arrives in the same second. Almost every subsystem you'd normally design - browse, search, checkout - is a solved problem here; the interview is really about one thing: a small pool of inventory as the single contended resource, and the machinery that protects it - admission control at the front, reservations with TTLs in the middle, idempotent payment at the back, and the explicit trade-off between never overselling and maximizing sell-through. Weak candidates design a web app; strong candidates design a queue draining into a counter.
Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.
Capacity estimation · architecture with all 8 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions
Get full access to gitGood.dev with a subscription.
Try everything free for 10 days. Cancel anytime.
10-day trial, then $5/mo - or $40/yr ($3.33/mo, save 33%). Cancel anytime.
Idempotency keys, double-spend prevention, the ledger model, and why eventual consistency is wrong for balances. The interview where ambiguity costs you money.
Five algorithms, three sharding strategies, one fail-open vs fail-closed decision. The bounded design that surfaces in every backend interview loop.
Partitions, consumer groups, replication, retention, and the exactly-once myth - the implementation details Kafka users gloss over until they don't.
Two-phase commit, sagas (choreography vs orchestration), TCC, idempotency keys, and the compensation logic that turns multi-service writes into something a customer-support agent can untangle.
Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.
Start an AI mock interview →