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

Resilient Payment and Database Layer

Problem/Feature Description

An e-commerce platform's checkout service calls Stripe for payment capture and PostgreSQL for order writes. During last month's product launch, a 12-second Stripe latency spike caused 4,000 in-flight requests to each hold a thread waiting for a response. The connection pool drained in under 90 seconds, the service stopped responding, and the ops team had to manually restart pods. Recovery took 11 minutes. Post-mortem identified two root causes: no mechanism to detect and fast-fail calls to an unhealthy Stripe, and no fallback path to keep orders flowing when payment capture is temporarily unavailable.

The team wants to wrap both the Stripe payment call and the database write in circuit breakers that fail fast once a service is struggling, track their state transitions in a format compatible with Prometheus, and fall back to a retry queue when payment fails rather than showing customers an error. Catalog reads should also be separated from writes: during sales the product pages generate enormous read traffic that should not compete with order writes for connections on the primary database. Frequently-accessed product data should be served from cache when available.

Output Specification

Write the following TypeScript files:

• circuit-breakers.ts — exports paymentCircuit and dbCircuit, their Prometheus metrics, and the fallback behavior for the payment circuit
• db-router.ts — exports a db object with read() and write() methods routing to separate connection pools, and a getProductCached() function

You may stub out the actual Stripe and database calls (e.g., captureStripePayment, writeOrderToDatabase) — focus on the circuit breaker wiring, metric instrumentation, fallback logic, and DB routing.

Include a config.md file (max 150 words) explaining the circuit breaker thresholds chosen and why timeout is the primary trigger.

Sneaker Drop Inventory Service

Problem/Feature Description

A streetwear brand is launching a limited-edition sneaker drop — only 500 pairs available — and expects roughly 80,000 unique visitors to hit the site within the first 30 seconds of the sale going live. Previous drops ran inventory checks against the PostgreSQL database: every checkout read the current stock, confirmed availability, then decremented in a separate write. Under high concurrency this race condition caused 120 pairs to be oversold during the last drop, triggering chargebacks and brand damage.

The team wants to rewrite the inventory layer to use an in-memory store for all reservation operations during the sale. Reservations must be fully atomic — no pair should be sold that doesn't exist — and if an order later fails during payment processing, the reservation must be returned to the pool. Because fair access matters for the brand's reputation, the team also wants a waiting room: customers who arrive when inventory is available get a queue position and are admitted in arrival order rather than at random.

Output Specification

Write a single TypeScript file inventory.ts implementing the following exported functions:

• initializeInventory(productId, quantity) — sets the initial stock count
• reserveInventory(productId, quantity) — atomically reserves stock; returns one of 'reserved', 'out_of_stock', or 'not_found'
• releaseInventory(productId, quantity) — returns stock to the pool when an order fails
• syncInventoryToDatabase() — writes current Redis stock counts back to the database
• enterWaitingRoom(sessionId, productId) — adds a customer to the fair queue; returns their position and a signed token
• admitFromQueue(productId, batchSize) — pops the next batch of customers from the queue and notifies them

You may use placeholder implementations for external calls (e.g., db.products.updateInventory, signQueueToken, notifyCustomerAdmitted) — focus on the Redis interaction logic.

Include a brief DESIGN.md file (max 200 words) explaining the atomicity guarantees of your inventory reservation approach.

Black Friday Checkout Service and Infrastructure Readiness

Problem/Feature Description

A fashion retailer is preparing for their biggest Black Friday sale. Last year the checkout API made a synchronous database write for every order, which worked fine at normal traffic but collapsed under the 40× spike when the sale opened. The database became the bottleneck, latency climbed above 30 seconds, and customers saw timeout errors before the team could scale. This year, the engineering team wants three things in place before the sale goes live.

First, the checkout API needs a fast path: accept an order, do the minimum work necessary, and immediately return a confirmation to the customer — without touching the database synchronously. Orders queued this way must be processed reliably in the background, with inventory reservations released and customers notified if processing fails. Second, the Kubernetes deployment needs an autoscaling configuration that can sustain the initial traffic surge, because reactive scaling alone won't spin up pods fast enough when thousands of visitors arrive simultaneously. Third, before the sale, the team needs to run a load test that simulates realistic Black Friday traffic — both shoppers racing to checkout and visitors browsing the catalog — to verify the system can handle more than just the expected peak.

Output Specification

Produce the following files:

• checkout.ts — the Next.js-style route handler (POST export) and the SQS consumer (processOrder export) implementing the fast-path checkout and background order processor
• hpa.yaml — Kubernetes HorizontalPodAutoscaler manifest for the checkout-service deployment
• load-test.yml — Artillery load test configuration file

You may stub external calls (e.g., capturePayment, sendOrderConfirmationEmail, reserveInventory) — focus on the SQS message structure, queue routing, and the shape of the configuration files.