A commerce platform prepares for its highest-traffic event of the year. What should a game day rehearse that ordinary load testing does not?

What load testing covers

That the system handles N times normal traffic. Necessary and insufficient, because it tests the system under a condition you chose, in a shape you predicted, with everything else healthy.

What a game day must add

1. Failure during peak, not instead of it. The realistic scenario is not "high traffic" but "high traffic and a degraded dependency". Rehearse a payment provider slowing down while at peak load, because that combination is what actually happens and it is where degradation ladders either work or do not.

2. The degradation ladder, every rung. Each capability that will be shed must be shed, under load, and the resulting experience observed. The characteristic finding is that shedding one feature breaks another in a way nobody predicted — the recommendation service was disabled and the homepage broke, because the fallback path had never been run.

3. The human response. Who is on call, do they have access, do the runbooks match reality, does the escalation path work, can the incident channel handle the volume of people who join. Most peak-event failures are extended, not caused, by response problems.

4. Communication. Status page updates, customer messaging, internal reporting. Deciding what to tell merchants during an outage is not something to improvise while the outage is happening.

5. Rollback and kill switches, actually operated. Not "we have a feature flag" but "we turned it off, observed the effect, and turned it back on". A control that has never been exercised is a hypothesis.

6. The recovery, which is where second outages happen. Returning traffic to a recovered component with cold caches and empty connection pools is how a resolved incident becomes a new one. Rehearse the ramp, not just the failure.

What makes it a game day rather than a test

People, decisions and ambiguity. A load test has a pass/fail result. A game day presents a situation with incomplete information and requires the team to diagnose and decide — which is precisely the skill that determines outcomes during a real event, and precisely what no automated test develops.

The output that matters

Not "we passed". The output is a list of specific defects with owners and dates: a runbook that was wrong, a dashboard that did not exist, a fallback that did not work, an alert that did not fire, a person who lacked access. A game day that finds nothing was not ambitious enough, and should be treated as a failed exercise rather than a successful one.