An exam window is a delivery problem, not a capacity one

Most web traffic is a distribution. Assessment traffic is an appointment: two thousand candidates start within the same four minutes because the window opens at nine, and they all finish within a few minutes of each other because the timer is the same length.

That shape breaks the intuitions that ordinary capacity planning is built on.

Why the spike is worse than its size

The load is synchronised, so queues do not smooth. It is write-heavy — every answer is a durable write, because losing one is not an option — so read replicas do not help. And it is deadline-bound: a request served ninety seconds late during an exam is not slow, it is a candidate whose timer ran while the page did not load.

There is also no shedding strategy. A retail site under pressure can degrade recommendations; an exam has no optional component. Everything on the page is the product.

The failures that actually happen

Session start, not session steady-state

Peak resource use is at the beginning: authentication, eligibility checks, form assembly, item media fetches, all at once. Steady-state answer submission is comparatively light. Load tests that ramp gradually miss this entirely, because the ramp is the thing being tested.

The submit at the end

The second spike is the one people forget. Timers expire together, and every session tries to finalise in the same window — the most write-intensive operation in the flow, at the moment the system has been under load longest.

Something adjacent

The exam holds up and the results portal falls over, or the notification mail queue backs up for six hours, or a reporting query locks a table the delivery path writes to. The blast radius of an exam window extends to everything sharing infrastructure with it, which is the argument for keeping the marketing site somewhere else entirely.

Preparation that earns its cost

Rehearse at real concurrency, against the production configuration, with the real form-assembly path. A synthetic test that skips assembly tests the wrong system.

Make the client resilient to the network rather than assuming it. Answers buffered locally and retried, with visible state so the candidate knows whether their work is saved, converts a connectivity blip from an incident into a pause.

Decide the extension policy before the window, not during it. If something does go wrong, the question "who gets more time, and how much" needs an answer that was written when nobody was under pressure — and the system needs to be able to grant it per candidate, which is a product capability, not an operational one.

What this means for the architecture

Anything that does not need to be in the delivery path should not be. Scoring, reporting, notifications, and analytics can all run behind the window rather than inside it, and separating them is what keeps a reporting mistake from becoming an exam incident.