Skip to content
advanced Phase 80 · Scaling Advanced

Flash Sale Preparation

Flash sale preparation including capacity planning, caching strategy, queue processing, and monitoring

45m
0 problems
Topic Progress 0%

Capacity Planning

Traffic Estimation

Flash Sale Traffic Multiplier:
- Normal: 1x baseline
- Pre-sale (1h before): 3-5x baseline
- Sale start: 10-50x baseline
- During sale: 5-20x baseline
- Post-sale: 2-3x baseline

Example:
- Baseline: 1000 req/sec
- Flash sale peak: 10,000-50,000 req/sec

Resource Scaling

Component        | Normal | Flash Sale | Scaling Method
─────────────────|────────|────────────|─────────────────
Web Nodes        | 2      | 8-10       | Auto-scaling
Database         | 1+1    | 1+3        | Add read replicas
Redis            | 3      | 6          | Cluster expansion
Varnish          | 2      | 4          | Add nodes
OpenSearch       | 3      | 6          | Add data nodes

Pre-Sale Checklist

# 1. Scale infrastructure
terraform apply -var='node_count=10'

# 2. Warm caches
bin/magento cache:clean
bin/magento cache:warm

# 3. Pre-index products
bin/magento indexer:reindex catalogsearch_fulltext

# 4. Clear old sessions
redis-cli FLUSHDB

# 5. Enable maintenance mode for deployment (if needed)
bin/magento maintenance:enable
bin/magento maintenance:disable

Caching Strategy

Aggressive Caching

// Increase cache TTL for flash sale
// Catalog pages: 24h → 7d
// Product pages: 1h → 24h
// Category pages: 30min → 4h

// Pre-warm critical pages
$urls = [
    '/flash-sale',
    '/flash-sale/widget',
    '/flash-sale/gadget',
    // ...
];

foreach ($urls as $url) {
    $this->cacheWarmer->warm($url);
}

Edge Caching

# Varnish: Cache all flash sale pages
if (req.url ~ "^/flash-sale") {
    unset req.http.Cookie;
    set req.http.X-Cache-Control = "public, max-age=86400";
    return (hash);
}

# CDN: Push flash sale content to edge
# Pre-deploy static assets to CDN edge nodes

Cache Invalidation Strategy

During Flash Sale:
- Product prices: NO cache (real-time inventory)
- Product details: Cache aggressively
- Cart/checkout: NO cache (dynamic)
- Static assets: Cache 7 days

Queue Processing

Order Queue Configuration

// Dedicated flash sale queue
// app/etc/env.php
'queue' => [
    'consumers' => [
        'flash.sale.orders' => [
            'maxMessages' => 10000,
            'consumer' => 'flash.sale.orders'
        ],
        'flash.sale.inventory' => [
            'maxMessages' => 5000
        ]
    ]
],

Inventory Reservation

// Reserve inventory in queue
$queue->publish('flash.sale.inventory.reserve', [
    'product_id' => $productId,
    'qty' => 1,
    'cart_id' => $cartId,
    'ttl' => 900 // 15 min reservation
]);

// Process reservations asynchronously
$consumer->process(function ($message) {
    $this->inventoryService->reserve($message->getProductId());
});

Order Processing Pipeline

1. Customer places order → Order queue
2. Reserve inventory → Inventory queue
3. Process payment → Payment queue
4. Send confirmation → Email queue
5. Update inventory → Index queue

Each step queued for reliability

Monitoring and Alerting

Key Metrics

Metric                  | Threshold | Action
────────────────────────|───────────|───────────────
Request latency p99     | >2s       | Scale web nodes
Queue depth             | >5000     | Add consumers
DB replication lag      | >5s       | Check primary load
Cache hit rate          | <70%      | Review cache config
Error rate              | >1%       | Investigate errors
Cart abandonment        | >50%      | Check checkout flow

Real-Time Dashboard

# Grafana dashboard queries
# Requests per second
rate(http_requests_total[1m])

# Response time histogram
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# Queue depth
rabbitmq_queue_messages{queue=~"flash.*"}

# Cache hit rate
redis_keyspace_hits / (redis_keyspace_hits + redis_keyspace_misses)

Emergency Procedures

1. If web nodes overloaded:
   → Auto-scale to max nodes
   → Enable static page cache

2. If database slow:
   → Enable query cache
   → Add read replicas

3. If queue backing up:
   → Add consumer processes
   → Enable backpressure

4. If cache hit rate drops:
   → Re-warm caches
   → Check for cache stampede

Quiz

1. What is the typical traffic multiplier for flash sale peak?

Question 1 options

2. Should flash sale prices be cached?

Question 2 options

3. What is the recommended queue depth alert threshold?

Question 3 options

Flashcards

Question

Flash sale traffic multiplier?

Click to reveal answer

Answer

10-50x normal traffic at peak

Question

Cache strategy for flash sales?

Click to reveal answer

Answer

Aggressive for details, no-cache for prices/inventory

Question

Inventory handling?

Click to reveal answer

Answer

Queue-based reservation with TTL

Question

Queue depth alert threshold?

Click to reveal answer

Answer

>5000 messages indicates consumer backlog

Revision Notes

Key Takeaways

  • 1. Flash sales see 10-50x normal traffic at peak
  • 2. Scale all infrastructure components before the sale
  • 3. Cache aggressively for static content, no-cache for prices
  • 4. Queue-based order and inventory processing for reliability
  • 5. Monitor key metrics and have emergency procedures ready

Interview Tips

  • • Explain capacity planning methodology for flash sales
  • • Discuss caching strategy trade-offs during high traffic
  • • Describe order processing pipeline and queue architecture

Cheat Sheet

Flash Sale Preparation:
  Traffic: 10-50x normal
  Scale: Web, DB, Cache, Search
  Pre-warm: Caches, indexes

Caching:
  Aggressive: Static content, product details
  No-cache: Prices, inventory, cart

Queues:
  Order → Inventory → Payment → Email
  Reserve inventory with TTL

Monitoring:
  Latency p99 <2s
  Queue depth <5000
  Cache hit >70%
  Error rate <1%