How Much Exam Platform Capacity Do You Actually Need?

When an examination platform fails, it rarely fails gradually. It fails at the worst possible moment — the opening minutes of a sitting, when every candidate logs in at once — and the institution, not the vendor, absorbs the consequences.

Sizing correctly starts with a single number that many specifications never state: peak concurrency.

Why enrolment numbers mislead

Total enrolment describes your population, not your load. A university with 40,000 students may never exceed 3,000 simultaneous candidates if assessments are distributed across a term. A licensing body with 10,000 annual candidates may put every one of them into a single national sitting.

The second case is far more demanding despite the smaller population — and a platform sized against enrolment would be sized against the wrong number entirely.

Calculating the number that matters

Work from your examination calendar rather than your registry:

1. Find your largest single sitting. How many candidates are scheduled in the same window?
2. Add the login spike. Candidates do not arrive evenly — most authenticate in the first few minutes. This is typically the true peak.
3. Account for overlap. Do separate exams run simultaneously? Their peaks add.
4. Add headroom. Growth, re-sits, and the sitting that gets rescheduled into an already busy week.
5. Include invigilators and administrators. They are concurrent users too, often with heavier dashboards.

The result is the figure your specification should state — and the figure vendors should respond to.

What to ask vendors to prove

A theoretical ceiling is not evidence. Ask instead:

• What is the highest concurrency you have run in production, and for which institution?
• What happened during the login spike at that scale?
• How does the platform behave under degradation — does it slow, queue, or fail?
• Can we load-test against our own peak figure before a live sitting?

That final question is the most useful one in the list. A vendor confident at your scale will agree to a rehearsal; one that hesitates is telling you something.

For reference, iTest is engineered for 120,000+ concurrent candidates and over 2 million exams a year, and delivers Egypt's national medical licensing examination (EMLE) — sat by 9,397 doctors for the Egyptian Health Council and Ministry of Health.

Capacity is not only about servers

Concurrency stresses more than infrastructure. At peak, three other things commonly break first:

• Authentication — especially where single sign-on routes through an institutional identity provider that was never load-tested for a simultaneous surge
• Integrations — an LMS or student information system pulled into the critical path at the wrong moment
• Proctoring — integrity processing carries its own load, and it scales with candidates, not with exams

Where systems must exchange data at that scale, the integration layer matters as much as the exam engine. Intrazero handles this with iMiddleware, which federates 500+ governmental university faculties in Egypt's national LMS programme.

Sizing and deployment interact

If your regulator requires on-premise deployment, your peak concurrency becomes an infrastructure requirement you must meet yourself. Establish the number before choosing the model, because it determines what you have to provision.

iTest supports cloud, on-premise and hybrid, and the concurrency figure should be agreed against the model you will actually run — not against the vendor's cloud benchmark if you intend to deploy locally.

The short version

State peak concurrency, not enrolment. Include the login spike. Ask what the vendor has run in production rather than what the datasheet claims. And rehearse at your real peak before the sitting that matters.