This article was originally featured on FE News.
When organisations set out to choose an online exam platform, the conversation almost always starts in the same place: question types, proctoring, marking and reporting. Those things matter, and they demo well. But in my experience they are rarely the reason an exam goes wrong on the day. The thing that decides whether a high-stakes exam succeeds or fails is usually invisible on a feature-comparison sheet — the infrastructure underneath it.
Why online exams are an unusual workload
It is tempting to assume that if a platform can serve a website, it can run an exam. It can't, or at least not reliably. Online assessment places demands on infrastructure that most software never has to handle.
The traffic arrives all at once
A cohort does not trickle in. Thousands of candidates click "start" within the same sixty seconds, then stay connected — saving answers, loading media, syncing state — for hours. That is a very different shape of load from a normal web app, and a platform that has not been engineered for high concurrency will show it exactly when it can least afford to.
Failure mid-exam is not recoverable
For most software, a brief outage is an inconvenience. In an exam, it is a candidate who loses their work, a cohort whose results are challenged, and an awarding body whose credibility takes the hit. The stakes change what "good enough" means. Resilience — graceful handling of a dropped connection, a browser crash, a flaky network — has to be designed in, not bolted on afterwards.
Every candidate's environment is different
You do not control the devices or networks your candidates use. Some sit in a managed test centre; others are at home on a laptop and a mobile hotspot, sometimes in genuinely challenging conditions. The platform has to hold up across all of it, which is a much harder engineering problem than serving a predictable, well-provisioned audience.
Why infrastructure gets overlooked
The honest answer is that features are easy to evaluate and resilience is not. You can see a proctoring dashboard in a demo. You cannot see how a platform behaves when ten thousand people start at once, or what happens when a data centre has a bad day — until it happens to you. So the visible layer gets the attention, and the layer that actually determines the outcome gets a line in the contract, if that.
Questions worth asking a vendor
If infrastructure is the blind spot, the fix is to shine a light on it during procurement. A few questions tend to be revealing:
- Concurrency: how many candidates can genuinely start and run at the same time, and how is that number established?
- Scaling: does capacity scale automatically for a big exam day, or does someone have to provision it in advance?
- Resilience: what happens to a candidate's attempt if their connection drops or their browser crashes mid-exam?
- Durability: how often is work saved, how are backups handled, and what are the recovery objectives if the worst happens?
- Track record: is there a public status page, and what does the incident history actually show?
Vague answers to these questions are themselves an answer. This is also where a serious security and data-protection posture tends to correlate with a serious infrastructure posture — the organisations that invest in one usually invest in the other.
Infrastructure, design and verification are layers of trust
None of this is an argument that infrastructure is the only thing that matters. It is an argument that it is a necessary foundation the others sit on. Dependable infrastructure, sound assessment design and identity verification are complementary layers of trust. A beautifully designed, well-proctored exam still fails if the platform falls over when the cohort logs in. And robust infrastructure does not, on its own, make an exam fair or valid.
The takeaway is not to stop caring about the visible features. It is to give the invisible layer the same scrutiny — because when a high-stakes exam is running and something goes wrong, it is almost never the question types that let you down.
This article was originally featured on FE News.
