Executive Summary
If you are planning a scholarship test, a mock series or a term-end exam for a large cohort, the question that matters is not how many learners the platform can hold. It is what happens in the four narrow windows where all of them do the same thing at the same moment. A full exam journey measured on production with 1,000 simultaneous candidates kept every step under half a second, filed every paper correctly, and left roughly two thirds of the server capacity unused. The rest of this piece explains which parts of exam day are actually hard, and how to check your own numbers before candidates sit down.
1. Exam Day Is Four Bursts, Not a Steady Stream
Most capacity conversations start with the wrong number. A thousand candidates spread across a two-hour exam is a modest, comfortable load — roughly seventeen save operations a second. What decides whether exam day holds is not that average at all. It is the four moments where a thousand people do the same thing within the same sixty seconds.
The sign-in burst
Candidates arrive in the quarter hour before the paper opens, often on devices they have not used for an exam before. This is short, sharp, and entirely front-loaded.
The start burst
Everyone presses Start within the same few minutes. Each candidate is served the full question paper, and an attempt is created for them. This is the heaviest read the system performs.
Continuous autosave
Answers and time state stream to the server throughout the attempt rather than only at the end. Predictable, steady, and the reason a dropped connection costs a candidate nothing.
The submission rush
Objective papers are scored as they are submitted, and late finishers cluster into the final two minutes. This is where an exam platform either holds or visibly stalls.
Capacity is set by the worst of those four windows, never by the average. An exam platform that looks perfectly healthy on a dashboard at 11:00 can still stall at 11:02 when the start burst lands, and again at the closing bell.
2. What We Measured at 1,000 Candidates
On 28 August 2026 we ran a complete exam journey against live production infrastructure — the same servers that serve institutes every day, not a scaled-up rig assembled for the occasion. One thousand simulated candidates signed in across a ten-minute window, started within three minutes of each other, worked through a thirty-question objective paper with autosaves every sixty seconds, and submitted.
The figures below are 95th-percentile times: the experience of the unluckiest candidate in every twenty, not a flattering average.
| Step in the exam | Response time | What it covers |
|---|---|---|
| Signing in | 146 ms | Candidate authentication as the exam window opens |
| Loading the paper | 465 ms | Delivering the full question paper to each candidate |
| Starting the exam | 134 ms | Everyone pressing Start inside the same few minutes |
| Autosaving answers | 140 ms | Continuous background saving during the attempt |
| Submitting | 139 ms | Final submission and scoring, including the end rush |
Zero failed requests across roughly 11,000 calls. All 1,000 papers were then checked individually in the database — every one submitted, scored and recorded. Exam servers peaked at under a third of their allocated capacity.
3. The Two Things That Actually Break
Here is the part worth taking away, whichever platform you run. At no point in our testing was the constraint the database, the network or the login service. Those sat idle. Both failure modes we found were software design problems, and both were invisible until a thousand people did the same thing simultaneously.
Anything a submission triggers — analytics, rank calculation, a notification — must run away from the request that the candidate is waiting on. If it does not, a thousand submissions consume every available request handler, and the queue backs up onto candidates who were doing nothing more demanding than autosaving an answer. The symptom is misleading: processor usage stays low while response times climb, because the threads are waiting rather than working.
A load test can report a perfect run while records are quietly wrong. In one round every submission returned success, yet a small share of attempts had not been stored as submitted — a background recalculation had overwritten them a moment later. No load-testing tool would have caught it. It only showed up because every attempt was checked against the database afterwards. That reconciliation step is now part of how we test, and it is the question worth asking any vendor who quotes you a concurrency number.
4. Resilience Is a Candidate Feature, Not an Infrastructure One
The exam experience is built for unreliable connections rather than assuming good ones. Answers and time state stream to the server continuously during the attempt, with a live network indicator on screen. If a browser crashes or a phone dies mid-paper, the candidate signs back in and rejoins the running attempt exactly where they were. Timers run at assessment, section and question level with automatic submission when they expire, so a lost device does not become a lost paper.
5. Exam Day Needs a Control Room
Capacity is only half the problem. The other half is what an invigilator can do at 11:20 when a candidate reports a frozen laptop. While the exam runs, staff see participants split into Attempted, Ongoing and Pending tabs with live counters, search and filters, and can act individually or in bulk.
Add extra time
Grant additional minutes to ongoing attempts, one candidate or many at once.
Close submissions
Force-submit attempts still running past the deadline, individually or in bulk.
Grant re-attempts
Give selected candidates another attempt after a genuine disruption.
Release results
Publish per candidate, in bulk, or for the whole assessment when set to manual release.
Candidates can also raise extra-time and re-attempt requests from inside the exam where the institute allows it, and staff approve them from the same console. Announcements broadcast to everyone mid-exam without interrupting anyone's attempt.
6. Written Papers Scale Better Than Screens
Exams where candidates upload a scanned answer sheet behave differently, and counter-intuitively they are lighter on the platform than on-screen papers. The candidate's device receives a secure, single-use link and uploads straight to cloud storage. The file itself never passes through the exam servers, which only handle the paperwork around it.
We measured that too: 1,000 candidates each uploading a six-page answer sheet of roughly one megabyte, 974 MB of candidate work in total. Every step our servers perform finished in under a fifth of a second, all 1,000 submissions were filed with their sheet attached and queued for marking, and the exam servers peaked at a tenth of their capacity. Because the bytes bypass the platform, a ten-megabyte scan costs it no more than a one-megabyte one — a larger file simply takes the candidate's own connection longer.
7. Build the Paper Faster Than You Schedule It
Scale is wasted if authoring the paper is the bottleneck. Papers can be assembled question by question, pulled from a searchable question bank, imported from a Word document with options and answer keys intact, or generated from existing material you already own.
The paper is usually the slow part
Most institutes already hold years of question papers as PDFs and documents. Turning that archive into structured, auto-gradable questions is what makes a weekly mock series realistic rather than aspirational — and it is a different job from serving the exam on the day.
8. What to Ask Before Your Next Large Exam
Whether you run your exams on Vacademy or elsewhere, these are the questions that separate a tested platform from a hopeful one:
- Has the number been measured, or estimated? Ask for the date, the cohort size and the response times per step — not a marketing figure.
- Was it measured on production? A dedicated test environment proves very little about the servers your candidates will actually hit.
- Were the results reconciled afterwards? Every attempt checked against the database, not just a green report from a load tool.
- What happens to a candidate who disconnects at minute forty? If the answer is anything other than “they rejoin the same attempt”, plan for disputes.
- Can staff intervene mid-exam? Extra time, force-submit and re-attempts are exam-day essentials, not luxuries.
Cohort size is only one variable. Paper length, image-heavy questions and answer-sheet size all change the arithmetic. For any unusually large exam we will simulate your specific setup and give you the measured numbers before your candidates sit down.