Flash Sale Scaling

Flash Sale Scaling

Overview

Flash sales and product drops generate traffic spikes 50–100× normal load, arriving within seconds of sale start. Without preparation, the checkout service collapses, inventory oversells, and customers see error pages. This skill covers the infrastructure patterns needed to handle extreme traffic: pre-warming, queue-based order intake with back-pressure, Redis-based atomic inventory reservation, and circuit breakers that degrade gracefully under load.

When to Use This Skill

• When planning a flash sale, limited product drop, or major promotional event
• When past sales have caused checkout timeouts, oversells, or database failures
• When Black Friday/Cyber Monday planning is underway and infrastructure needs review
• When a new product announcement is expected to drive sudden high-demand traffic

Core Instructions

Step 1: Determine your platform and what you can control

Step 2: Platform-specific flash sale preparation

Shopify

Shopify handles scaling automatically and can handle virtually any traffic spike. Your prep work is:

1. Enable Shopify's high-demand checkout queue (Shopify Plus):

   • Go to Online Store → Preferences → Checkout
   • Enable Checkout concurrency — this activates Shopify's virtual waiting room for high-traffic drops
   • For limited-inventory products (product drops): use the built-in inventory reservation so customers who enter checkout have their item held for 10 minutes

2. Use Launchpad (Shopify Plus) for sale scheduling:

   • Install Launchpad from the Shopify App Store (free for Plus merchants)
   • Schedule sale start/end times, price changes, and inventory availability in advance
   • Launchpad handles atomic activation at the scheduled time — avoid manual price changes under load

3. Pre-test your store performance (all Shopify plans):

   • Go to Online Store → Themes and click View report to see your store's Core Web Vitals
   • Run Google PageSpeed Insights on your most critical pages (product page, collection page, checkout)
   • Fix any red/orange issues before the sale — compressing images is the most common fix

4. Notify Shopify support before major launches (Shopify Plus):

   • Submit a Flash Sale notification via your Plus support channel — Shopify can pre-allocate resources and monitor your store during the event

WooCommerce

WooCommerce requires significant infrastructure work before a high-traffic event:

Hosting upgrade (most critical):

1. Ensure your hosting plan can scale: use Cloudways (horizontal scaling with one click), Kinsta (auto-scaling), or WP Engine (auto-scaling add-on) — not shared hosting
2. If on shared hosting, migrate to a VPS or managed WordPress host at least 1 week before the sale to allow stabilization
3. On Cloudways: go to Servers → [server] → Vertical Scaling before the event and select a larger server size; scale back down after

Cache stack:

1. Install and configure WP Rocket (page cache) + Redis Object Cache (database query cache)
2. WP Rocket: enable Preload cache to warm pages before the sale starts
3. Redis Object Cache: verify Redis is active (green status in Settings → Redis)
4. Enable Cloudflare and set Caching level to Standard; add your store URLs to Cloudflare Page Rules with Cache Everything for product and shop pages

Inventory oversell prevention:

1. Enable WooCommerce's built-in inventory management: WooCommerce → Settings → Products → Inventory → check Enable Stock Management
2. Set Hold stock (minutes) to 60 — this holds an item in a customer's cart for 60 minutes before releasing it back to inventory
3. For limited items: set Allow backorders to Do not allow so the product goes out-of-stock exactly at 0 inventory

Load test before the sale:

1. Use Loader.io (free tier: 1 target, 10K connections) to simulate your expected peak traffic against your staging site
2. Test the checkout flow specifically — product browse is usually cached; checkout hits the database
3. Fix any failures or slow responses before the sale date

Custom / Headless

Pre-warm infrastructure (run 30 minutes before sale start):

# Kubernetes: scale checkout deployment up before sale
kubectl scale deployment checkout-service --replicas=50

# Or schedule automatic scaling with a CronJob
# See the CronJob example below

Atomic inventory reservation with Redis (prevents oversells):

// lib/inventory.js
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

// Initialize inventory in Redis before the sale
export async function initializeInventory(productId, quantity) {
  await redis.set(`inventory:${productId}`, quantity);
}

// Atomic check-and-decrement using Lua script (runs on Redis server, no race conditions)
const LUA_RESERVE = `
  local current = tonumber(redis.call('GET', KEYS[1]))
  if current == nil then return -1 end
  if current < tonumber(ARGV[1]) then return 0 end
  redis.call('DECRBY', KEYS[1], tonumber(ARGV[1]))
  return 1
`;

export async function reserveInventory(productId, quantity) {
  const result = await redis.eval(LUA_RESERVE, 1, `inventory:${productId}`, quantity);
  if (result === 1) return 'reserved';
  if (result === 0) return 'out_of_stock';
  return 'not_found';
}

export async function releaseInventory(productId, quantity) {
  await redis.incrby(`inventory:${productId}`, quantity);
}

Queue-based order intake (fast response, async processing):

// checkout API — responds instantly, processes in background
export async function POST(req) {
  const order = await req.json();

  // 1. Reserve inventory atomically
  const reservation = await reserveInventory(order.productId, order.quantity);
  if (reservation === 'out_of_stock') {
    return Response.json({ error: 'Sold out' }, { status: 409 });
  }

  // 2. Enqueue — responds to user in <100ms
  const orderId = crypto.randomUUID();
  await sqs.send(new SendMessageCommand({
    QueueUrl: process.env.ORDER_QUEUE_URL,
    MessageBody: JSON.stringify({ orderId, ...order }),
  }));

  return Response.json({
    orderId,
    status: 'queued',
    message: 'Your order is being processed. You will receive a confirmation email shortly.',
  });
}

// Background order processor (separate service consuming SQS)
export async function processOrder(message) {
  const order = JSON.parse(message.Body);
  try {
    await capturePayment(order);
    await db.orders.create(order);
    await sendOrderConfirmationEmail(order);
  } catch (err) {
    await releaseInventory(order.productId, order.quantity); // release on failure
    throw err; // let SQS retry
  }
}

Circuit breaker for payment processor:

import CircuitBreaker from 'opossum';

const paymentBreaker = new CircuitBreaker(captureStripePayment, {
  timeout: 5000,                 // 5s timeout per call
  errorThresholdPercentage: 30,  // open if 30% fail
  resetTimeout: 30000,           // try again after 30s
});

// Fallback: queue for retry instead of failing the customer
paymentBreaker.fallback(async (order) => {
  await sqs.send(new SendMessageCommand({
    QueueUrl: process.env.PAYMENT_RETRY_QUEUE_URL,
    MessageBody: JSON.stringify(order),
    DelaySeconds: 30,
  }));
  return { status: 'payment_queued' };
});

Kubernetes pre-scale CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: flash-sale-prescale
spec:
  schedule: "30 11 * * 5"  # 30 min before noon Friday sale
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: scaler
              image: bitnami/kubectl
              command: [kubectl, scale, deployment/checkout-service, --replicas=100]
          restartPolicy: OnFailure

Redis waiting room for extremely high-demand drops:

// Fair queue: customers get a position number when they arrive
export async function enterWaitingRoom(sessionId, productId) {
  const queueKey = `sale_queue:${productId}`;
  await redis.zadd(queueKey, Date.now(), sessionId); // sorted set, score = timestamp (FIFO)
  const position = await redis.zrank(queueKey, sessionId);
  return { position: (position ?? 0) + 1 };
}

// Periodically admit batches to checkout
export async function admitFromQueue(productId, batchSize) {
  const admitted = await redis.zpopmin(`sale_queue:${productId}`, batchSize);
  // Notify each admitted customer they can proceed to checkout
  for (let i = 0; i < admitted.length; i += 2) {
    await notifyCustomerAdmitted(admitted[i], productId);
  }
}

Best Practices

• Reserve inventory in Redis, not the database — atomic Redis operations handle thousands of concurrent reservations per second; PostgreSQL row locking under the same load causes timeouts and deadlocks
• Accept orders into a queue during spikes — the user-facing checkout should respond in under 100ms even at peak; defer payment capture, DB writes, and emails to background workers
• Set aggressive timeouts on every external call — a 30-second Stripe timeout under load multiplies into thousands of held connections; use 5-second timeouts with circuit-breaker escalation
• Load test at 2–3× expected peak — test at exactly expected capacity leaves no headroom; size for 3× to account for uneven traffic distribution
• Communicate queue status to customers — show real-time position in the waiting room; customers with visible progress are far more patient than those staring at a spinner

Common Pitfalls

Related Skills

• @database-optimization-commerce
• @ecommerce-caching
• @monitoring-alerting-commerce
• @load-testing-commerce
• @edge-commerce