##### Question Design a high-concurrency ticketing / flash-sale system for limited inventory (e.g. tickets to a popular concert with a fixed number of seats). At on-sale time the system must absorb sudden spikes of up to millions of concurrent purchase attempts per second while guaranteeing inventory correctness. Cover the following: 1. **Admission control & fairness.** Handle the stampede with a virtual waiting room / queue. Choose and justify a fairness model (FIFO by arrival, or a lottery), and explain rate limiting, token buckets, and backpressure so that admission rate matches backend capacity rather than incoming traffic. 2. **No oversell.** Guarantee strict inventory correctness with zero oversell for both general-admission (count-only) and reserved-seating (specific seats) modes. Explain reservation vs. immediate deduction, short-lived reservations with payment timeouts (TTL), and how seats/units are released on expiry or cancellation. 3. **Anti-bot & abuse.** Describe bot mitigation (WAF, device fingerprinting, CAPTCHA / proof-of-work, behavioral signals), token binding, and per-identity purchase quotas (e.g. max 2-4 tickets per account/device/card). 4. **Idempotent order creation & safe retries.** Make order/reservation creation idempotent (idempotency keys) so client retries and duplicate webhooks never double-charge or double-allocate. 5. **Hot-key sharding.** Avoid a single global counter hot spot. Explain how you shard inventory across keys/shards and spread load (e.g. token lists per shard, hash-tagged Redis keys, seat bitmaps). 6. **APIs.** Sketch the key endpoints (join queue, poll queue status, acquire reservation, create order, payment callback, cancel reservation, get availability / order status), including idempotency headers and standardized error codes. 7. **Data model & partitioning.** Define the entities (events, SKUs/seats, reservations, orders, payments, idempotency) and the partition/shard keys for the durable store and for the Redis hot path. 8. **Caching, read/write paths & real-time availability.** Explain cache usage (Redis cluster as the in-sale authoritative allocator), the read path for real-time availability (polling vs. WebSocket/SSE), and the write path from queue to reservation to paid order. 9. **Message queues & delivery semantics.** Use an async bus (Kafka/Pulsar/SQS) for decoupling, retries, and DLQs; explain at-least-once delivery, idempotent consumers, and the transactional outbox/inbox pattern. 10. **Consistency model & reconciliation.** State your consistency choices (strong for allocation via atomic ops, eventual for availability reads), the role of the DB as durable ledger vs. Redis as allocator, and how you periodically reconcile the two. 11. **Failure handling & degradation.** Cover timeouts, retries with backoff/jitter, circuit breakers, brownout modes, Redis/DB/PSP failure handling, and reservation-expiry reapers. 12. **Capacity planning, SLOs & load testing.** Provide concrete capacity estimates (QPS, admission rate, Redis/DB/queue sizing), latency targets (p99), and a load-testing / chaos-testing plan that proves zero oversell under extreme load. 13. **Monitoring & alerting.** List the key metrics (oversell count, queue backlog, reservation expiry rate, latency quantiles, DLQ depth, payment success rate) and the alert thresholds. Note: the company is TikTok (a consumer app / content platform); treat this as a generic flash-sale / limited-inventory design problem, not a specific TikTok product.

TikTok software-engineer system-design interview question: design a high-concurrency ticketing / flash-sale system that survives millions of concurrent purchase attempts with zero oversell. It tests admission control and fairness (virtual waiting room, FIFO vs lottery), atomic inventory allocation with TTL reservations, anti-bot defenses, idempotent order creation, hot-key sharding, the data model and APIs, caching, message queues and delivery semantics, consistency and reconciliation, failure handling, capacity planning, SLOs, load testing, and monitoring.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at TikTok.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at TikTok during technical interviews.

Design a high-concurrency ticketing system

Question

Design a high-concurrency ticketing / flash-sale system for limited inventory (e.g. tickets to a popular concert with a fixed number of seats). At on-sale time the system must absorb sudden spikes of up to millions of concurrent purchase attempts per second while guaranteeing inventory correctness. Cover the following:

Admission control & fairness. Handle the stampede with a virtual waiting room / queue. Choose and justify a fairness model (FIFO by arrival, or a lottery), and explain rate limiting, token buckets, and backpressure so that admission rate matches backend capacity rather than incoming traffic.
No oversell. Guarantee strict inventory correctness with zero oversell for both general-admission (count-only) and reserved-seating (specific seats) modes. Explain reservation vs. immediate deduction, short-lived reservations with payment timeouts (TTL), and how seats/units are released on expiry or cancellation.
Anti-bot & abuse. Describe bot mitigation (WAF, device fingerprinting, CAPTCHA / proof-of-work, behavioral signals), token binding, and per-identity purchase quotas (e.g. max 2-4 tickets per account/device/card).
Idempotent order creation & safe retries. Make order/reservation creation idempotent (idempotency keys) so client retries and duplicate webhooks never double-charge or double-allocate.
Hot-key sharding. Avoid a single global counter hot spot. Explain how you shard inventory across keys/shards and spread load (e.g. token lists per shard, hash-tagged Redis keys, seat bitmaps).
APIs. Sketch the key endpoints (join queue, poll queue status, acquire reservation, create order, payment callback, cancel reservation, get availability / order status), including idempotency headers and standardized error codes.
Data model & partitioning. Define the entities (events, SKUs/seats, reservations, orders, payments, idempotency) and the partition/shard keys for the durable store and for the Redis hot path.
Caching, read/write paths & real-time availability. Explain cache usage (Redis cluster as the in-sale authoritative allocator), the read path for real-time availability (polling vs. WebSocket/SSE), and the write path from queue to reservation to paid order.
Message queues & delivery semantics. Use an async bus (Kafka/Pulsar/SQS) for decoupling, retries, and DLQs; explain at-least-once delivery, idempotent consumers, and the transactional outbox/inbox pattern.
Consistency model & reconciliation. State your consistency choices (strong for allocation via atomic ops, eventual for availability reads), the role of the DB as durable ledger vs. Redis as allocator, and how you periodically reconcile the two.
Failure handling & degradation. Cover timeouts, retries with backoff/jitter, circuit breakers, brownout modes, Redis/DB/PSP failure handling, and reservation-expiry reapers.
Capacity planning, SLOs & load testing. Provide concrete capacity estimates (QPS, admission rate, Redis/DB/queue sizing), latency targets (p99), and a load-testing / chaos-testing plan that proves zero oversell under extreme load.
Monitoring & alerting. List the key metrics (oversell count, queue backlog, reservation expiry rate, latency quantiles, DLQ depth, payment success rate) and the alert thresholds.

Note: the company is TikTok (a consumer app / content platform); treat this as a generic flash-sale / limited-inventory design problem, not a specific TikTok product.

Question

Admission control & fairness. Handle the stampede with a virtual waiting room / queue. Choose and justify a fairness model (FIFO by arrival, or a lottery), and explain rate limiting, token buckets, and backpressure so that admission rate matches backend capacity rather than incoming traffic.
No oversell. Guarantee strict inventory correctness with zero oversell for both general-admission (count-only) and reserved-seating (specific seats) modes. Explain reservation vs. immediate deduction, short-lived reservations with payment timeouts (TTL), and how seats/units are released on expiry or cancellation.
Anti-bot & abuse. Describe bot mitigation (WAF, device fingerprinting, CAPTCHA / proof-of-work, behavioral signals), token binding, and per-identity purchase quotas (e.g. max 2-4 tickets per account/device/card).
Idempotent order creation & safe retries. Make order/reservation creation idempotent (idempotency keys) so client retries and duplicate webhooks never double-charge or double-allocate.
Hot-key sharding. Avoid a single global counter hot spot. Explain how you shard inventory across keys/shards and spread load (e.g. token lists per shard, hash-tagged Redis keys, seat bitmaps).
APIs. Sketch the key endpoints (join queue, poll queue status, acquire reservation, create order, payment callback, cancel reservation, get availability / order status), including idempotency headers and standardized error codes.
Data model & partitioning. Define the entities (events, SKUs/seats, reservations, orders, payments, idempotency) and the partition/shard keys for the durable store and for the Redis hot path.
Caching, read/write paths & real-time availability. Explain cache usage (Redis cluster as the in-sale authoritative allocator), the read path for real-time availability (polling vs. WebSocket/SSE), and the write path from queue to reservation to paid order.
Message queues & delivery semantics. Use an async bus (Kafka/Pulsar/SQS) for decoupling, retries, and DLQs; explain at-least-once delivery, idempotent consumers, and the transactional outbox/inbox pattern.
Consistency model & reconciliation. State your consistency choices (strong for allocation via atomic ops, eventual for availability reads), the role of the DB as durable ledger vs. Redis as allocator, and how you periodically reconcile the two.
Failure handling & degradation. Cover timeouts, retries with backoff/jitter, circuit breakers, brownout modes, Redis/DB/PSP failure handling, and reservation-expiry reapers.
Capacity planning, SLOs & load testing. Provide concrete capacity estimates (QPS, admission rate, Redis/DB/queue sizing), latency targets (p99), and a load-testing / chaos-testing plan that proves zero oversell under extreme load.
Monitoring & alerting. List the key metrics (oversell count, queue backlog, reservation expiry rate, latency quantiles, DLQ depth, payment success rate) and the alert thresholds.

Note: the company is TikTok (a consumer app / content platform); treat this as a generic flash-sale / limited-inventory design problem, not a specific TikTok product.

Design a high-concurrency ticketing system

Quick Overview

Design a high-concurrency ticketing system

Question

Submit Your Answer to Earn 20XP

Design a high-concurrency ticketing system

Quick Overview

Design a high-concurrency ticketing system

Question

Submit Your Answer to Earn 20XP