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
▶
Request Trace
Step 1/8
API Gateway

Receives user HTTP order request

Validates request and forwards to Rate Limiter

Protocol:HTTP/HTTPS
BeforeUser request arrives at API Gateway
AfterRequest validated and sent to Rate Limiter
Rate Limiter

Checks request rate limits

Allows request if under limit, rejects if exceeded

Protocol:Internal RPC
BeforeRequest pending rate limit check
AfterRequest passed rate limiting and forwarded to Load Balancer
Load Balancer

Routes request to an Order Service instance

Balances load across multiple Order Service replicas

Protocol:gRPC
BeforeRequest queued for processing
AfterRequest assigned to Order Service instance
Order Service

Processes order and checks inventory

Calls Inventory Service to verify stock availability

Protocol:gRPC
BeforeOrder details received, inventory unknown
AfterInventory confirmed or rejected for order
Inventory Service

Reads inventory count from Redis Cache

If cache miss, reads from Cassandra DB and updates cache

Protocol:Redis GET/SET
BeforeInventory count unknown in cache
AfterInventory count retrieved from cache or DB and cache updated if needed
Inventory Service

Reads inventory count from Cassandra DB on cache miss

Fetches durable inventory data from Cassandra DB

Protocol:CQL
BeforeInventory count not found in Redis Cache
AfterInventory count retrieved from Cassandra DB
Cassandra DB

Stores order and inventory updates

Persists order data and decrements inventory count

Protocol:CQL
BeforeOrder and inventory changes not persisted
AfterOrder and inventory changes durably stored in Cassandra DB
Notification Service

Sends order confirmation notification

Notifies user of successful order placement

Protocol:Internal RPC
BeforeOrder completed but user not notified
AfterUser receives order confirmation notification
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP/HTTPS
        ▼
┌───────────────┐
│ Rate Limiter  │
└───────┬───────┘
        │ Internal RPC
        ▼
┌───────────────┐
│ Load Balancer │
└───────┬───────┘
        │ gRPC
        ▼
┌───────────────┐
│ Order Service │
└───────┬───────┘
        │ gRPC
        ▼
┌───────────────────┐
│ Inventory Service │
└───────┬───────────┘
        │ Redis GET/SET
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ CQL
        ▼
┌───────────────┐
│ Cassandra DB  │
└───────┬───────┘
        │ Internal RPC
        ▼
┌─────────────────────┐
│ Notification Service│
└─────────────────────┘
Design Rationale

This Flash Sale System architecture handles 10x traffic spikes by layering rate limiting and load balancing to protect backend services. The API Gateway receives user requests and forwards them to the Rate Limiter, which prevents overload by rejecting excess requests. The Load Balancer distributes allowed requests evenly to Order Service instances, which coordinate order processing. Inventory Service uses Redis Cache for fast stock checks, falling back to Cassandra DB for durable data. Cassandra ensures persistent storage of orders and inventory updates. Finally, Notification Service asynchronously informs users of order success. This design balances fast in-memory caching with durable storage and protects system stability during flash sale surges.

Primary Focus

✓

Practice

(1/5)
1. A job portal must handle 10,000 concurrent search queries per second with low latency and support complex filters on job attributes. Which component is best suited to handle this search workload?
easy
A. A distributed search engine like Elasticsearch with inverted indexes
B. A message queue to buffer search requests before processing
C. A key-value store like Redis caching recent search results
D. A relational database with indexed columns for filtering

Solution

  1. Step 1: Identify search workload characteristics

    High concurrency and complex attribute filtering require fast full-text and faceted search capabilities.

  2. Step 2: Evaluate component suitability

    Relational DBs (A) struggle with complex full-text and scale; Redis (C) is a cache, not a search engine; message queues (D) buffer but don't execute search queries. Elasticsearch (B) provides distributed inverted indexes optimized for such queries.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Distributed inverted indexes -> low-latency complex search [check]
Hint: Distributed inverted indexes power scalable complex search [check]
Common Mistakes:
2. In a microservices architecture, a client request flows through API Gateway -> Auth Service -> Order Service -> Inventory Service. At step 3, the Order Service calls Inventory Service synchronously. What happens if Inventory Service is slow at step 3?
easy
A. Auth Service caches Inventory Service response to speed up future calls
B. Order Service queues the request asynchronously and immediately returns success to client
C. API Gateway retries the Inventory Service call automatically without client awareness
D. Order Service blocks the client request until Inventory Service responds or times out

Solution

  1. Step 1: Trace synchronous call behavior at step 3

    Order Service calls Inventory Service synchronously, so it waits for response before replying to client.

  2. Step 2: Analyze impact of slow Inventory Service

    Because of synchronous call, client request blocks until Inventory Service responds or times out; no immediate return or retries happen automatically.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Synchronous calls block caller until response or timeout [check]
Hint: Synchronous calls block caller until response or timeout [check]
Common Mistakes:
3. For a chat application requiring low latency message delivery but tolerating occasional message loss, which architecture best balances latency and throughput?
medium
A. Use a batch processing system that aggregates messages every 5 seconds
B. Use a synchronous request-response system with guaranteed delivery acknowledgments
C. Use an asynchronous message queue with at-least-once delivery and eventual consistency
D. Use a distributed cache with write-through persistence for all messages

Solution

  1. Step 1: Analyze latency vs throughput needs

    Batch processing adds latency but can increase throughput and tolerate some message loss.

  2. Step 2: Evaluate architectures

    Synchronous (A) increases latency; asynchronous queue (B) reduces latency but may cause duplicates; distributed cache (D) lacks delivery guarantees; batch (C) balances throughput with acceptable latency for some use cases.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Batching trades latency for throughput, tolerating some loss [check]
Hint: Batching trades latency for throughput and tolerates loss [check]
Common Mistakes:
4. At 10x scale, which component in a Blue-Green deployment system is most likely to fail first and why?
hard
A. Deployment pipeline because build servers cannot handle 10x concurrent builds, delaying releases
B. Green environment servers because maintaining two full production environments doubles resource usage and costs
C. Load balancer because it must instantly switch traffic for millions of users, causing connection storms
D. Feature flag service because it cannot handle 10x toggle evaluations per request

Solution

  1. Step 1: Identify scaling bottlenecks

    Blue-Green requires two full environments; load balancer scales horizontally; feature flags scale independently.

  2. Step 2: Analyze deployment pipeline

    Build servers face 10x concurrent builds, causing queueing and delays, blocking releases.

  3. Step 3: Compare other components

    Load balancer and feature flags can be sharded; doubling environment cost is expensive but not a failure.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Build servers bottleneck at 10x concurrent builds, delaying deployments [check]
Hint: Build servers choke first at 10x concurrent builds, blocking deploys [OK]
Common Mistakes:
5. At 10x scale, which component is most likely to become the bottleneck in a WebSocket-based chat system, and why?
hard
A. The chat servers, because WebSocket connections are stateful and bound to server memory, making horizontal scaling and connection migration difficult.
B. The database, because it cannot handle the increased write volume from message persistence.
C. The load balancer, because it cannot efficiently distribute WebSocket connections due to their stateful nature.
D. The client browsers, because they cannot maintain more than a few WebSocket connections simultaneously.

Solution

  1. Step 1: Identify stateful components in WebSocket architecture

    WebSocket connections are stateful and maintained in server memory, binding clients to specific chat servers.

  2. Step 2: Analyze scaling challenges

    At 10x scale, chat servers face difficulty resharding connections or migrating them, limiting horizontal scaling. Databases and load balancers can be scaled more easily. Client browser limits are less impactful at system scale.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    WebSocket stateful connections -> chat servers bottleneck at scale [check]
Hint: Stateful WebSocket connections bind clients to servers -> chat servers 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