Bird
Raised Fist0

Design a Flash Sale System - Handling 10x Traffic Spike in 60 Seconds

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Flash Sale System - Handling 10x Traffic Spike in 60 Seconds
Design a flash sale platform that can handle sudden 10x traffic spikes within 60 seconds with strong consistency and high availability.
hardE-Commerce and PaymentsFreq: high
Prerequisites:IdempotencyACID Transactions
⚙️
Functional Requirements
  • Handle flash sale product inventory with strong consistency to prevent overselling.
  • Support user order placement with idempotency to avoid duplicate orders during retries.
  • Provide real-time inventory updates and availability status to users.
  • Process payments and confirm orders atomically with inventory deduction.
  • Throttle and queue excess traffic during the flash sale peak to maintain system stability.
  • Send order confirmation notifications asynchronously after successful order placement.
📊
Non-Functional Requirements
  • Support up to 10x traffic spike within 60 seconds, e.g., from 100K to 1M QPS writes.
  • Achieve 99.99% availability during flash sale events.
  • Maintain end-to-end order placement latency under 100ms P99.
  • Ensure data durability with replication and backups for at least 30 days.
  • Handle peak read QPS of at least 5M for inventory and order status queries.
❓
Clarifying Questions to Ask
  • What is the expected baseline QPS before the flash sale spike?
  • Is strong consistency required for inventory updates or eventual consistency acceptable?
  • What is the maximum acceptable order placement latency during peak traffic?
  • Are partial orders allowed if inventory runs out mid-transaction?
  • What is the expected average order size and payload size?
  • Is the flash sale limited to a single product or multiple products simultaneously?
Out of Scope
✗ Designing the payment gateway internals (assume third-party payment processor).
✗ User authentication and authorization mechanisms.
✗ Detailed UI/UX design for the flash sale frontend.
✗ Long-term analytics and reporting beyond 30 days retention.
📌
Assumptions
  • Baseline write QPS before flash sale: 100K writes/sec
  • Flash sale spike multiplier: 10x → peak write QPS = 1M writes/sec
  • Average message size per write (order + inventory update): 200 bytes
  • Average read QPS during flash sale: 5M reads/sec (inventory + order status)
⚡
QPS Calculation
write qps100K writes/sec baseline
peak write qps100K × 10 = 1,000,000 writes/sec
read qps5,000,000 reads/sec peak during flash sale
💾
Storage Estimate
daily writes bytes1,000,000 writes/sec × 200 bytes × 86400 sec = 17.28 TB/day
retention days30
total storage bytes17.28 TB/day × 30 days = 518.4 TB
with replication518.4 TB × 3 replicas = 1.555 PB total storage
🖥️
Server Estimate
write db nodesAssuming Cassandra with 50K writes/sec per node → 1,000,000 / 50,000 = 20 nodes
cache nodesRedis cluster with 100K reads/sec per node → 5,000,000 / 100,000 = 50 nodes
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |  User Clients  |
          +-------+--------+
                  |
          +-------v--------+
          |  API Gateway   |
          +-------+--------+
                  |
          +-------v--------+
          |  Rate Limiter  |
          +-------+--------+
                  |
          +-------v--------+
          | Load Balancer  |
          +-------+--------+
                  |
  +---------------+----------------+
  |                                |
  v                                v
Order Service                  Inventory Service
  |                                |
  +---------------+----------------+
                  |
          +-------v--------+
          |  Cassandra DB  |
          +-------+--------+
                  |
          +-------v--------+
          |  Redis Cache   |
          +-------+--------+
                  |
          +-------v--------+
          | Notification Svc|
          +----------------+
🧩
Components
API Gateway
Entry point for all client requests, handles authentication, routing, and throttling.
Why thisEnvoy proxy supports dynamic routing and rate limiting with low latency and high throughput.
Why notNginx lacks native dynamic service discovery and fine-grained rate limiting at this scale.
Rate Limiter
Protects backend services by enforcing request limits per user/IP during flash sale spikes.
Why thisRedis with Lua scripts provides atomic counters and sub-millisecond latency for rate limiting.
Why notIn-memory local rate limiting cannot coordinate across distributed API gateway instances.
Order Service
Handles order placement, enforces idempotency, and coordinates inventory deduction with ACID guarantees.
Why thisJava microservice using Spring Boot with distributed transaction support via Saga pattern and Cassandra lightweight transactions.
Why notMonolithic architecture would not scale horizontally to handle 1M writes/sec.
Inventory Service
Manages inventory counts with strong consistency to prevent overselling during flash sales.
Why thisCassandra with lightweight transactions (LWT) provides linearizable conditional updates at scale.
Why notMySQL with master-slave replication cannot handle 1M writes/sec and causes replication lag.
Cassandra DB
Primary data store for orders and inventory with high write throughput and multi-region replication.
Why thisCassandra scales linearly with nodes, supports LWT for conditional updates, and offers tunable consistency.
Why notPostgreSQL requires complex manual sharding and does not scale linearly at 1M writes/sec.
Redis Cache
Caches inventory and order status for low-latency reads during flash sale peak.
Why thisRedis TTL natively expires stale data without cron jobs, supports high QPS with cluster mode.
Why notMemcached lacks persistence and advanced data structures needed for inventory state.
Notification Service
Sends asynchronous order confirmation notifications via email/SMS after order success.
Why thisKafka consumer-based microservice decouples notification sending from order processing for resilience.
Why notSynchronous notification sending blocks order processing and increases latency.
Load Balancer
Distributes incoming requests evenly across API gateway instances to ensure availability and scalability.
Why thisHAProxy supports high throughput, health checks, and flexible routing policies.
Why notDNS round-robin lacks health checks and fine-grained load distribution control.

Practice

(1/5)
1. In a distributed database, at Step 4 the coordinator node receives conflicting writes from two partitions during a network split. What state does the coordinator enter immediately after Step 4?
easy
A. Coordinator marks the writes as conflicting and delays commit until partition heals
B. Coordinator commits both writes immediately to maintain availability
C. Coordinator rejects all writes to maintain consistency during partition
D. Coordinator forwards writes to a third node to resolve conflicts synchronously

Solution

  1. Step 1: Trace coordinator behavior at Step 4

    The coordinator detects conflicting writes from partitions and cannot commit both safely.

  2. Step 2: Understand conflict resolution

    It marks writes as conflicting and delays commit until partitions heal to avoid inconsistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Coordinator defers conflicting writes until partition resolution [check]
Hint: Coordinator delays conflicting writes until partition heals [check]
Common Mistakes:
2. In the timeline generation flow, at step 4 the Delivery Worker reads from Kafka and checks the follower's timeline cache TTL. What happens if the cache TTL has expired for a follower at this step?
easy
A. The Delivery Worker triggers a timeline rebuild for that follower before delivering
B. The Delivery Worker retries reading the cache until TTL refresh completes
C. The Delivery Worker writes the tweet directly to the follower's timeline DB without cache refresh
D. The Delivery Worker skips the follower and marks the message as delivered

Solution

  1. Step 1: Understand Delivery Worker cache TTL check

    If TTL expired, the cached timeline is stale and must be rebuilt to ensure fresh data.

  2. Step 2: Evaluate actions on expired TTL

    Skipping (A) loses data; direct DB write (C) bypasses cache rebuild; retrying cache read (D) causes blocking and delays.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL triggers timeline rebuild to maintain freshness [check]
Hint: Expired cache TTL triggers timeline rebuild [check]
Common Mistakes:
3. In a MongoDB data model using the bucket pattern for time-series data, at step 3 of the write flow, the system checks if the current bucket document is full. What happens if the bucket is full at this step?
easy
A. A new bucket document is created and the write is appended there to maintain document size limits.
B. The write is rejected and the client must retry with a new bucket ID.
C. The existing bucket document is updated by splitting it into two smaller documents automatically.
D. The write is appended to the existing bucket document regardless of size, risking document growth beyond limits.

Solution

  1. Step 1: Understand bucket pattern write flow

    Writes append to a bucket document until size or time limits are reached.

  2. Step 2: Behavior when bucket is full

    System creates a new bucket document to avoid exceeding MongoDB's 16MB document size limit.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    New bucket created to respect document size limits [check]
Hint: Full bucket triggers new document creation to avoid size limit [check]
Common Mistakes:
4. In a request trace, at step 4 the latency monitoring component records the request's completion time. If the request took 120ms but the P95 latency threshold is 100ms, what state does the monitoring component mark for this request?
easy
A. Request is ignored because it is below P99 latency
B. Request is marked as within acceptable latency
C. Request is marked as exceeding P95 latency threshold
D. Request is marked as failed due to timeout

Solution

  1. Step 1: Compare request latency to P95 threshold

    The request latency (120ms) exceeds the P95 threshold (100ms), so it is in the slowest 5% tail.

  2. Step 2: Monitoring component's marking logic

    Requests exceeding P95 latency are flagged to identify performance degradation; it is not ignored or marked as failed unless timeout occurs.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    120ms > 100ms P95 -> marked as exceeding P95 latency [check]
Hint: Latency > P95 threshold -> mark as slow request [OK]
Common Mistakes:
5. At 10x scale, which component of a distributed HyperLogLog-based unique user counting system is most likely to fail first, and why?
hard
A. The aggregator node, because it must merge many HyperLogLog sketches and becomes CPU-bound
B. The HyperLogLog register storage, because fixed-size registers cannot represent larger cardinalities accurately
C. The network bandwidth between servers, because merging large raw user ID sets saturates links
D. The user ID ingestion layer, because it must hash and update many HyperLogLog sketches concurrently

Solution

  1. Step 1: Analyze scaling impact on components

    Network bandwidth is low since only fixed-size sketches are transferred, not raw IDs; register size is fixed and does not fail but accuracy degrades slightly.

  2. Step 2: Identify bottleneck

    The aggregator merges many sketches concurrently, increasing CPU load and latency, making it the first to fail under 10x load.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Aggregator CPU-bound merging many sketches first bottleneck [check]
Hint: Aggregator CPU merges many sketches -> first bottleneck [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard