Most consumer platforms face demand that varies by a factor of two or three across a day. Education platforms face something different: weeks of near-idle traffic followed by a morning where every student in a cohort logs in during the same ten minutes because an exam opens at nine. The load is extreme, but unlike a viral spike it is known months in advance, and that changes what good engineering looks like. This is edtech work where the deadline is set by a timetable nobody can move.
01A predictable spike is a different problem
Autoscaling is built for demand that ramps. Exam-season load does not ramp: it steps, from almost nothing to peak, in under a minute. By the time a scaling policy has observed the metric, waited out its cooldown and started instances, the exam has begun and the students who could not log in are already filing complaints.
Because the date is known, the correct answer is usually to pre-scale rather than to autoscale. Provision for the peak before the window opens, hold it through the exam, and scale down afterwards. It costs more than reactive scaling for those hours and it is the only approach that reliably works.
02The database is almost always the ceiling
Application servers scale out easily. The database does not, and exam load is unusually hostile to it: thousands of sessions created in the same minute, each writing progress continuously, against a working set that no longer fits in cache because every student is touching different content.
Connection exhaustion arrives first. Each new application instance opens its own pool, so scaling the tier that looks overloaded multiplies connections against a database that has a hard limit, and the platform gets slower precisely as more capacity is added.
- Put a connection pooler in front of the database before scaling the application tier.
- Move session state out of the primary database so login storms do not contend with exam writes.
- Route reporting and dashboard queries to a replica; staff refresh them constantly during exams.
- Batch progress writes rather than persisting every keystroke.
- Know the connection ceiling as a number, and alert before it, not on it.
03Load test the shape, not the volume
A test that applies the peak request count evenly across an hour proves very little. The failure mode is the simultaneity: everyone authenticating, loading the same paper and starting to write within the same short window, which produces contention that an averaged test never creates.
Model the actual arrival pattern. Ramp from idle to peak in the time the real cohort takes, replay the real sequence of operations, and include the staff dashboards refreshing alongside. Teams routinely discover that the system handles the volume and fails on the shape.
| Scenario | What it exposes |
|---|---|
| Whole cohort logs in within one minute | Auth and session store limits |
| All students open the same paper | Cache stampede on identical content |
| Continuous autosave from every session | Write throughput and lock contention |
| Staff dashboards refreshing throughout | Reporting queries competing with exam writes |
| Mass submission at the closing bell | The second peak teams forget to test |
04The closing bell is a second peak
Teams prepare for the start of an exam and forget the end. When a paper closes, every remaining student submits at once, and a submission is far more expensive than an autosave: it finalises the attempt, triggers grading, writes an audit record and often generates a document.
That peak is narrower and heavier than the login spike. Queue the expensive downstream work rather than performing it inline, so the student gets a fast confirmation and the grading pipeline drains at its own pace. What must never happen is a submission failing because a grading service is saturated.
05Degrade in the right order
Under genuine overload something has to give, and the system should decide in advance rather than failing wherever the pressure happens to land. Ranking functionality by consequence turns an outage into a reduced service.
Exam delivery and submission come first. Everything else, analytics, dashboards, notifications, recommendation panels, can be shed. Building explicit switches for the lower tiers means the decision is a configuration change under pressure rather than an emergency deployment.
- Tier one: authentication, paper delivery, autosave, submission.
- Tier two: progress views for students and invigilator monitoring.
- Tier three: analytics, reporting exports, notification emails.
- Put tier three behind a feature flag that operations can disable without a release.
- Rehearse the shed sequence before the season, not during it.
06Rehearse the season, not just the system
The technical readiness work is the easier half. The other half is operational: who is watching during the window, what they are authorised to do without escalation, how the institution is informed if something degrades, and what the fallback is if the platform is unavailable when a timetabled exam should start.
Run a full rehearsal against production capacity in the weeks before the season, with the on-call rota staffed as it will be on the day. Rehearsals surface the coordination gaps that no load test can, and they are considerably cheaper than discovering them live in front of a cohort.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.