Results Day Is Your Super Bowl. Most School ERPs Are Built for a Tuesday

Every school and university IT team knows the date. In some systems it is board results, in others it is admissions offers or timetable release. Whatever it is called locally, the shape is identical: fifty weeks of comfortable, predictable load, and then one morning where the entire community arrives at the same URL within about ten minutes.

And nearly every year, in nearly every institution, it falls over. Not because anyone was negligent, but because the system was sized for the Tuesday it experiences 99.7% of the time.

This is a live-event traffic problem. It is structurally the same as a stadium at kickoff, and it should be engineered the same way.

Why the usual scaling advice does not save you#

The instinctive answer is “put it on the cloud and enable autoscaling.” That answer fails on results day for three specific reasons, and understanding them is most of the fix.

Autoscaling is too slow for a ten-minute spike. Scaling policies observe a metric, wait for it to breach a threshold for a sustained period, then provision instances that take a minute or more to become healthy. Your spike is over — or your system has already collapsed — before capacity arrives. Autoscaling handles growth over hours. It does not handle a step function.

The database does not scale the way the web tier does. You can add ten application servers in three minutes. You cannot add a primary database. Every one of those new app servers opens connections to the same database, and connection exhaustion converts a load problem into a total outage. More app servers can actively make results day worse.

The traffic is not random, it is coordinated. Ten thousand users spread across an hour is trivial. Ten thousand users in ninety seconds, all requesting the same handful of endpoints, is a different system entirely. Queueing theory is unkind here: utilisation approaching capacity produces latency that grows without bound, and users respond to slowness by refreshing, which adds load, which increases slowness. The feedback loop is the outage.

What actually works#

Five things, roughly in order of leverage.

1. Pre-render everything you can, and serve it from the edge.

The single highest-leverage move. A student’s result is known before it is published. It does not need to be computed on request. Generate the static payload in advance, publish it to object storage behind a CDN at release time, and your origin serves approximately zero traffic for the thing everyone wants.

This is the same principle behind the 117 Tbps the World Cup final pushed through a CDN with an origin that barely noticed: make the hot object cacheable and the scale problem stops being yours. For a portal, it is even easier, because unlike live video the content is known in advance.

2. Split the read path from the write path.

Results viewing is read-only. It has no business touching the transactional database that runs admissions, attendance and fees. Give the read path its own replica or, better, its own pre-computed store. Then a results-day surge cannot take down enrolment processing, and the blast radius of getting it wrong is one feature instead of the whole institution.

3. Make the payload small.

A results page that ships 4 MB of JavaScript framework, web fonts and analytics is a network problem before it is ever a server problem — and your users are on mobile networks that are themselves congested because everyone in the catchment is doing the same thing simultaneously.

We have fixed more results-day complaints by cutting page weight than by adding capacity. Server-rendered HTML with minimal JavaScript is not nostalgia here; it is the correct engineering answer for a page that must load once, fast, on a bad connection, for everyone at once. The same reasoning that keeps our own site light applies with more force when the audience is synchronised.

4. Queue deliberately rather than fail randomly.

If some component genuinely cannot be scaled — a legacy integration, a per-student PDF generator — put a real queue in front of it with a visible position indicator. Users tolerate “you are number 340, about two minutes” far better than a spinner that times out. An honest queue also protects the backend by bounding concurrency, which a spinner does not.

5. Rehearse it.

This is the one that gets skipped, and it is the one that matters. Load test at three times your expected peak, on production-equivalent infrastructure, at least two weeks before the date. Not a synthetic benchmark of one endpoint — the actual journey, with authentication, with the real payload, with realistic think times and the refresh behaviour of frustrated users.

The tournament analogue is instructive: nine matches exceeded 70 Tbps before the final hit 117. The system was not tested for the first time on the biggest night. Yours should not be either, and unlike a World Cup, you get to choose when the rehearsal happens.

The failure modes we find in load tests#

Every results-day load test we have run has surfaced at least one of these, and none of them are visible under normal traffic:

• A login endpoint that hashes passwords with an expensive work factor — correct security, catastrophic when ten thousand people authenticate in one minute. The fix is not weaker hashing; it is a session strategy that does not require simultaneous fresh logins, and pre-issued access links where the security model allows.
• An N+1 query in a page that renders fine with one user — 40 queries per page view is invisible at 5 requests per second and lethal at 500.
• A third-party dependency with no timeout — an analytics beacon or SSO provider that degrades takes your page with it because nobody set a deadline on the call.
• Log volume saturating disk or a log-shipping pipeline — verbose request logging at 100x normal volume has taken down more systems than the traffic itself.
• A cache that everyone misses at once — cold cache plus synchronised arrival means every request goes to the origin. Warm it before release, and use request coalescing so a thousand simultaneous misses become one backend call.

The organisational bit#

Results day has an advantage most capacity problems lack: you know the date, months in advance.

That makes it one of the few reliability problems that is fully plannable, which in turn makes failure genuinely avoidable rather than merely unlucky. The engineering is a couple of weeks of work. The reason it does not happen is that in July nobody is thinking about it, and in the week before, there is no time left to change anything.

So the practical advice is a calendar entry, not an architecture diagram. Six weeks out: load test. Four weeks out: fix what the test found. Two weeks out: retest and freeze. On the day: watch, do not deploy.

A School ERP that survives its worst hour builds more institutional trust than one that is slightly nicer to use for the other fifty weeks. Parents and students remember the morning it did not work.

---

You know exactly when your peak is. There is no excuse for meeting it unprepared. We load test, fix and rehearse before the date. Tell us when yours is.