Spike and stress for sales events

The question you must answer before every BFCM is: at what load does our system break? If you do not know the answer, your customers will find it for you on the highest-revenue day of the year. Spike and stress tests answer that question deliberately, in a controlled environment, while you still have time to fix it.

Before you start

• The full-funnel load test from end-to-end journey load passes at your modeled peak VU count.
• Failure criteria are configured on the test so the breaking point is captured automatically.
• Stakeholders know this test will cause errors and may cause temporary unavailability on the target environment.
• You are running against staging, not production.

Why separate tests: spike vs. stress

A spike test and a stress test find different breaking points:

Test type	Load shape	What it finds
Spike	Near-instant jump to 5×–10× normal	Connection pool exhaustion, session store saturation, cold-start failure under sudden load
Stress	Gradual ramp to 2×–5× normal	The concurrency ceiling, database lock contention, CPU/memory saturation

For BFCM you need both. A doorbuster is a spike problem. Sustained Cyber Monday traffic is a stress problem. Running only one type gives you half the answer.

Running the spike test

What BFCM spike looks like

A flash-sale spike jumps from warm idle (50–100 VUs) to 5×–10× your modeled peak in under 30 seconds. The system has no time to autoscale. Any resource that is lazily initialized or connection-pool limited will fail immediately.

Spike test configuration

execution:
  - scenario: bfcm-spike
    stages:
      - duration: 2m
        target: 100       # warm idle baseline
      - duration: 20s
        target: 6800      # 5× peak — doorbuster shock
      - duration: 5m
        target: 6800      # hold at shock level
      - duration: 2m
        target: 100       # drop and observe recovery
      - duration: 5m
        target: 100       # recovery window

scenarios:
  bfcm-spike:
    requests:
      - url: https://api.staging.example.com/v1/products/flash-deal
        label: GET /products/flash-deal
      - url: https://api.staging.example.com/v1/cart/items
        label: POST /cart/items
        method: POST
        headers:
          Content-Type: application/json
        body: '{"product_id": "flash-deal-001", "qty": 1}'

1. Create a new test named bfcm-2025-doorbuster-spike in the MaxoPerf console.
2. Upload the YAML above as the entrypoint.
3. Add failure criteria: POST /cart/items p95 > 2000ms and error rate > 5 % — these are the thresholds at which the spike is considered “broken.”
4. Click Run and watch the Overview tab. The spike will be clearly visible in the VU chart.
5. Note the exact VU count and timestamp when error rate first exceeds 1 %. This is the practical breaking point.

How to read the spike result

• Error rate during hold — any errors are acceptable if they stop the moment VUs drop. Persistent errors after VU drop indicate the system has not recovered.
• Connection errors vs. application errors — HTTP 5xx from your application means logic failure; TCP connection errors mean the system stopped accepting new connections entirely (much worse).
• Recovery time — how long after VU drop does error rate return to zero? Under 60 seconds is good. Over 5 minutes suggests connection pool or state corruption.

Running the stress test

What BFCM stress looks like

Sustained Cyber Monday traffic is a slow burn: 3×–4× your average daily traffic, all day. The stress test finds the concurrency ceiling — the VU count above which performance degrades unacceptably — so you can ensure your peak is comfortably below it.

Stress test configuration

execution:
  - scenario: bfcm-stress
    stages:
      - duration: 3m
        target: 340       # 25 % of modeled peak
      - duration: 10m
        target: 340
      - duration: 3m
        target: 680       # 50 % of modeled peak
      - duration: 10m
        target: 680
      - duration: 3m
        target: 1360      # 100 % — modeled peak
      - duration: 10m
        target: 1360
      - duration: 3m
        target: 2040      # 150 % — safety margin target
      - duration: 10m
        target: 2040
      - duration: 3m
        target: 2720      # 200 % — push to find the break
      - duration: 10m
        target: 2720
      - duration: 5m
        target: 0

1. Create a new test named bfcm-2025-stress-ramp in the MaxoPerf console.
2. Upload the YAML above. Set failure criteria: p95 > 2000ms or error rate > 5 %.
3. Run the test. Do not stop early — the inflection point often appears at the 150 %–200 % stage.
4. When the run completes (or auto-fails on criteria), open the Overview tab.
5. Find the inflection point: the stage where p95 latency bends sharply upward or error rate rises above 0.5 %.

The goal is to confirm the inflection point is at at least 150 % of your modeled peak. That gives you a 50 % headroom buffer above the traffic you are planning for. If the inflection is at 110 % of modeled peak, you have almost no margin and must fix bottlenecks before the event.

Danger

Do not run a stress test that pushes 2×–5× peak load against a staging environment that shares downstream services (database, payment processor sandbox) with other teams. Coordinate a maintenance window or isolate the target before running above 150 % modeled peak. A stress test that DOS-es a shared sandbox will cause cross-team incidents.

Documenting the breaking point

After both tests, record:

Test	Breaking-point VUs	Breaking-point metric	Headroom above modeled peak
Spike (doorbuster)	4,200 VUs	TCP connection errors	3.1× modeled peak
Stress (gradual ramp)	2,100 VUs	p95 payment > 2000ms	1.54× modeled peak

If headroom is below 1.5× on either test, prioritize fixing the bottleneck before the dress rehearsal at T-1 week.

Where to go next

• Soak and stability — after confirming the breaking point is above your peak, prove multi-hour stability at your modeled load.
• Stress test — the full stress test reference page.
• Spike test — the full spike test reference page.
• War-room and runbook — use the breaking-point VU count to define your game-day abort criteria.