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
45 min · senior
senior

You are building a flash sale platform for a startup with 50M daily active users (DAU). During flash sales, traffic spikes by 10x within 60 seconds, causing extreme load on the system. The system must handle this spike gracefully, ensuring inventory consistency, low latency (P99 < 200ms), and secure transactions with encryption. The flash sale items have limited stock, and overselling must be prevented. The system should also provide real-time feedback to users about purchase success or failure.

Constraints
  • Handle 10x traffic spike within 60 seconds without downtime or degradation
  • Ensure inventory consistency and prevent overselling under concurrent requests
  • P99 latency for purchase requests must be under 200ms
  • All sensitive data must be encrypted in transit and at rest
  • Support eventual consistency for analytics but strong consistency for inventory
  • System must be resilient to partial failures and support graceful degradation
📋
Guided Steps
1/5
Step 1
Handling Traffic Spike and Load Balancing
How would you design the system to handle a sudden 10x traffic spike within 60 seconds without crashing?
💡 Hint
Consider front-door components that can absorb bursts and distribute load evenly.
Key Decision
Use AWS Application Load Balancer (ALB) with auto-scaling EC2 instances behind it to horizontally scale the web tier dynamically based on CPU and request metrics.
Interviewer Expectation
Mid: Names load balancer and auto-scaling. Senior: Explains how ALB supports sticky sessions if needed and how auto-scaling policies are tuned to react within seconds to traffic spikes.
⚠️Common Wrong Answer
Using a fixed number of servers without auto-scaling - leads to server overload and request failures during spikes.
Step 2
Inventory Management and Overselling Prevention
How will you ensure inventory consistency and prevent overselling when thousands of purchase requests hit simultaneously?
💡 Hint
Think about strong consistency databases and atomic operations or distributed locks.
Key Decision
Use Redis with Lua scripts for atomic decrement of inventory counters combined with a strongly consistent database like Amazon DynamoDB with conditional writes for final confirmation.
Interviewer Expectation
Mid: Mentions Redis for fast counters. Senior: Explains Lua scripting for atomicity and fallback to DynamoDB conditional writes to prevent race conditions and overselling.
⚠️Common Wrong Answer
Using only eventual consistent databases like Cassandra for inventory - causes overselling due to write conflicts.
Step 3
Ensuring Low Latency and High Throughput
What technologies and design patterns will you use to keep P99 latency under 200ms during peak load?
💡 Hint
Consider caching, asynchronous processing, and minimizing synchronous calls in the critical path.
Key Decision
Use Redis as a read-through cache for inventory and user session data, combined with asynchronous order processing via Kafka to decouple user requests from backend processing.
Interviewer Expectation
Mid: Suggests caching to reduce DB hits. Senior: Details Redis TTL strategies, Kafka partitioning keyed by item_id to maintain order, and how async processing reduces request blocking.
⚠️Common Wrong Answer
Synchronous writes to relational DB on every request - causes high latency and DB bottlenecks.
Step 4
Security and Data Encryption
How will you ensure all sensitive data is encrypted in transit and at rest, especially payment and user information?
💡 Hint
Think about TLS, encryption at rest, and key management services.
Key Decision
Use TLS 1.3 for all client-server communication, AWS KMS for managing encryption keys, and enable encryption at rest on DynamoDB and S3 storage.
Interviewer Expectation
Mid: Mentions TLS and encryption at rest. Senior: Explains key rotation policies, envelope encryption, and integration with AWS KMS for compliance and auditability.
⚠️Common Wrong Answer
Relying only on HTTPS without encryption at rest - exposes data if storage is compromised.
Step 5
API Design for Purchase Flow
Design 3 core API endpoints to support the flash sale purchase flow and inventory status checks.
💡 Hint
Consider endpoints for purchase initiation, inventory query, and purchase confirmation or failure notification.
Key Decision
POST /purchase to initiate purchase with user_id and item_id; GET /inventory/{item_id} to check real-time stock; POST /purchase/ack to confirm purchase success or failure asynchronously.
Interviewer Expectation
Mid: Names endpoints and basic parameters. Senior: Explains idempotency keys on purchase, optimistic concurrency control, and asynchronous acknowledgement to improve UX and reliability.
⚠️Common Wrong Answer
Single synchronous purchase endpoint without inventory check - leads to poor UX and overselling.
🔌
API Design Challenge
Sketch 3 core API endpoints for the flash sale system that handle user purchase flow and inventory status.
Hints
  • How does the client initiate a purchase request and what parameters are required?
  • How does the client check real-time inventory availability or sale status?
  • How does the system acknowledge purchase success or failure to the client?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of load balancer with auto-scaling to handle traffic spikes
  • Atomic inventory decrement using Redis Lua scripts
  • Strong consistency with DynamoDB conditional writes to prevent overselling
  • Caching layer to maintain low latency under load
  • Encryption in transit and at rest with proper key management
Good to Have - 30%
  • Asynchronous order processing with Kafka partitioned by item_id
  • API design supporting idempotency and async acknowledgement
  • Graceful degradation strategies during partial failures
  • Auto-scaling policies tuned for rapid scaling
  • Use of optimistic concurrency control for inventory updates
Bonus - 10%
  • Detailed explanation of key rotation and audit compliance
  • Use of Redis TTL and heartbeat for session management
  • Partitioning strategies in Kafka to maintain order guarantees
  • Fallback mechanisms for cache misses during peak load
Anti-patterns to Avoid
Fixed server pool without auto-scaling causes crashes under spike load due to inability to handle sudden traffic increases.
Using eventual consistent databases like Cassandra for inventory leads to overselling because of write conflicts and lack of strong consistency.
Synchronous writes to relational databases on every request cause high latency and database bottlenecks during peak load.
Relying only on HTTPS without encryption at rest exposes sensitive data if storage is compromised.
Single synchronous purchase endpoint without inventory check leads to poor user experience and overselling.
HTTP polling at 50M DAU results in 50 million reconnects per minute just to check for messages, collapsing the system under load.
✅
Model Answer
▼ Reveal

This flash sale system design addresses handling a 10x traffic spike within 60 seconds by leveraging auto-scaling load balancers, atomic inventory management, low latency caching, asynchronous order processing, and strong security measures. It ensures inventory consistency, prevents overselling, maintains P99 latency under 200ms, and provides real-time user feedback with secure transactions.

Key Decisions
  • Use ALB with auto-scaling EC2 instances to handle sudden 10x traffic spikes dynamically and maintain availability.
  • Implement atomic inventory decrement using Redis Lua scripts to prevent overselling under concurrent requests.
  • Use DynamoDB conditional writes to ensure strong consistency and final confirmation of inventory updates.
  • Employ Redis as a read-through cache to reduce database load and maintain low latency (P99 < 200ms).
  • Process orders asynchronously via Kafka partitioned by item_id to maintain order and decouple user requests from backend processing.
  • Secure all sensitive data with TLS 1.3 in transit and AWS KMS-managed encryption at rest with key rotation policies.
  • Design APIs with POST /purchase (with idempotency keys), GET /inventory/{item_id}, and POST /purchase/ack for async acknowledgement to improve UX and reliability.
  • Tune auto-scaling policies for sub-minute reaction times to traffic spikes to avoid request failures.
  • Use optimistic concurrency control and conditional writes to avoid race conditions in inventory updates.
  • Implement graceful degradation by serving cached inventory data when backend systems are partially unavailable.
  • AWS Application Load Balancer with auto-scaling EC2 instances to handle 10x traffic spikes dynamically
  • Redis with Lua scripting for atomic inventory decrement to prevent overselling under concurrency
  • Amazon DynamoDB with conditional writes for strong consistency and final inventory confirmation
  • Kafka with item_id partition key for asynchronous order processing and maintaining order per item
  • Redis as a read-through cache to reduce database load and maintain P99 latency under 200ms
  • TLS 1.3 for encryption in transit and AWS KMS for encryption at rest with key rotation policies
  • API design with POST /purchase, GET /inventory/{item_id}, and POST /purchase/ack endpoints supporting idempotency and async acknowledgement
  • Auto-scaling policies tuned for sub-minute reaction to traffic spikes to avoid request failures
  • Use of optimistic concurrency control and conditional writes to avoid race conditions in inventory updates
  • Graceful degradation by serving cached inventory data when backend systems are partially unavailable

Practice

(1/5)
1. In a file storage system, at step 3 the client requests a file write. What happens inside the metadata server at this step?
easy
A. The metadata server sends the file data to object storage for persistence.
B. The metadata server writes the file data blocks directly to disk.
C. The metadata server updates the file's inode and directory entries to reflect the new write.
D. The metadata server caches the entire file in memory without updating disk metadata.

Solution

  1. Step 1: Understand metadata server role in file write

    The metadata server manages file metadata like inodes and directory entries, not the actual data blocks.

  2. Step 2: Trace what happens at step 3

    On a write request, the metadata server updates the inode and directory metadata to reflect changes; data blocks are handled separately by storage nodes.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Metadata server updates inode, not data blocks [check]
Hint: Metadata server updates metadata, not file data blocks [check]
Common Mistakes:
2. If the cache invalidation mechanism for the Trie shards fails, what is the most likely failure observed in the typeahead suggestions?
medium
A. Users see outdated suggestions that do not reflect recent data updates
B. The system crashes due to memory overflow in the Trie cache
C. Suggestions become empty because the Trie cache returns null on failure
D. Personalization ranking fails but prefix matching remains accurate

Solution

  1. Step 1: Understand cache invalidation role

    Cache invalidation ensures Trie shards reflect recent data; failure means stale data remains served.

  2. Step 2: Analyze failure impact

    Memory overflow (B) or empty suggestions (C) are unrelated to invalidation failure; personalization ranking (D) is separate from cache invalidation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Failed invalidation -> stale suggestions served [check]
Hint: Failed cache invalidation -> stale suggestions served [check]
Common Mistakes:
3. For the review system, which architecture better supports real-time aggregation of review scores for millions of listings with minimal latency, given that eventual consistency is acceptable?
medium
A. Use a stream processing system like Apache Flink to aggregate reviews in real-time
B. Use a relational database with complex joins and transactions for immediate consistency
C. Use batch processing with daily MapReduce jobs to update aggregated scores
D. Use a NoSQL document store with denormalized review aggregates updated on each write

Solution

  1. Step 1: Identify real-time aggregation needs

    Millions of listings require low-latency updates; immediate consistency is not mandatory.

  2. Step 2: Evaluate architectures

    Relational DB (A) is costly and slow at scale; batch jobs (C) have high latency; NoSQL denormalization (D) risks write amplification and stale data. Stream processing (B) provides scalable, low-latency aggregation with eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stream processing enables scalable real-time aggregation with eventual consistency [check]
Hint: Stream processing fits real-time aggregation with eventual consistency [check]
Common Mistakes:
4. Without the Outbox Pattern in an event-driven saga, what exact failure occurs when a service crashes after committing its local transaction but before publishing the event?
medium
A. The saga coordinator retries the event automatically ensuring eventual delivery
B. The local transaction is rolled back automatically, so no inconsistency occurs
C. The event is published twice causing duplicate side effects downstream
D. The event is lost, causing downstream services to never receive the update and saga to stall

Solution

  1. Step 1: Trace failure without Outbox Pattern

    Service commits DB transaction but crashes before event publish, so event never reaches message broker.

  2. Step 2: Consequence of lost event

    Downstream services never receive update; saga waits indefinitely or inconsistently proceeds.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Crash after commit but before publish -> event lost, saga stalls [check]
Hint: Crash after DB commit but before event publish loses event [check]
Common Mistakes:
5. If the Kafka cluster responsible for fan-out message delivery crashes, what is the exact failure observed in the News Feed system?
medium
A. New posts are lost permanently and never delivered to followers
B. The system blocks new post writes until Kafka recovers, causing user-facing delays
C. Followers receive duplicate feed updates due to Kafka replaying messages
D. Delivery Workers cannot fetch fan-out messages, so followers see stale feeds until recovery

Solution

  1. Step 1: Understand Kafka's role in fan-out delivery

    Kafka acts as a durable queue for fan-out messages. If it crashes, Delivery Workers cannot fetch new messages, causing stale feeds.

  2. Step 2: Evaluate failure modes

    Posts are not lost immediately (A) due to Kafka's durability; writes are asynchronous so no blocking (B); duplicates (D) occur only on replay, not crash.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka crash stalls delivery, causing stale feeds [check]
Hint: Kafka crash stalls delivery, causing stale feeds [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