I could sell high availability to every school that asks me about it, and most of them would sign. Uptime is an easy thing to be afraid of, and fear closes deals. That is exactly why I try not to lead with it. A lot of schools do not need high availability, and telling a small program that it does is a way to spend a budget that should have gone to teaching. So before I explain what it takes, I want to be honest about who it is for.
I have written separately about what high availability actually requires in general terms: the redundancy, the failover, the way you stop any single machine from being the reason the whole thing goes dark. This piece is not that. This piece is about what changes when the users are students, because education breaks the general rules in ways that surprise people who have only ever run high availability for a store or a marketing site.
Downtime for a school is measured in students, not dollars
When a store goes down, the company loses sales. That is a real cost, and you can put a dollar figure on it, and the dollar figure is usually what justifies the spend. When a school goes down, the cost lands somewhere else. It lands on a student who could not upload an assignment before the deadline, a class that could not join the live session, a cohort that lost the last twenty minutes of a timed exam. You cannot bill that back. You cannot run it again cleanly, because the moment was shared and the moment is gone.
That is the shift I ask every education client to sit with first. High availability for a school is not insurance against lost revenue. It is insurance against a student being the only one in the room who could not do the thing everyone else did, through no fault of their own. Once you frame it that way, the question of whether you need it gets a lot clearer, and so does the question of how much of it you need.
The load patterns that break a school on the wrong night
A restaurant kitchen that comfortably serves a steady trickle of tables all evening will still come apart when three tour buses pull into the lot and everyone orders at seven o’clock sharp. Same kitchen, same cooks, the same number of meals across the night. The only thing that changed is that they all arrived at once. Schools run on that kind of load, and it is the part naive setups get wrong.
A learning platform that is perfectly healthy on a normal Tuesday afternoon faces a handful of predictable stampedes. Enrollment opens at the start of term and thousands of people hit the same pages in the same hour. An assignment is due at 11:59 and an entire cohort submits in the final ten minutes, because that is when students submit. An exam window opens and everyone is in the system at the same time, answering, saving, and clicking submit together. A synchronous class starts and a lecture hall of people all connect inside the same minute.
Average traffic tells you almost nothing about any of these. A site can be sized correctly for its daily average and still fall over on submission night, because the average hides the peak where everyone acts together. When I size infrastructure for a school, I am not sizing for the Tuesday. I am sizing for the worst ten minutes of the busiest night of the term, and I am testing against that specific shape of load before it happens rather than after.
The single points of failure people forget
Here is where education gets genuinely different, and where I see the most money spent in the wrong place. A school will invest in a redundant web tier, feel protected, and leave the actual weak links untouched, because the weak links are the parts a general checklist does not mention.
High availability on the web servers does nothing for you if the single sign-on is what fails. If students log in through the institution’s identity provider and that integration goes down, it does not matter how many web servers you are running. Nobody can get in the front door. The same is true of the student information system: if the connection that carries enrollment and roster data stalls, the platform can be up and still be useless, because it does not know who anyone is.
Video is its own quiet failure point. A recorded lecture that plays fine for one person will choke when an entire section streams it at the same hour, and video delivery is a different problem from web delivery, with different limits. And then there is the one that keeps me up: grade data with no tested restore path. Plenty of schools have backups. Far fewer have ever restored one and confirmed the grades came back intact. A backup you have never restored is a hope, not a plan.
Real high availability for a school is the whole chain: sign-on, student data, content, video, and a restore you have actually rehearsed. Hardening one link and calling it done gives you the confidence without the protection, which is worse than knowing you are exposed.
When a school actually needs this, and when it doesn’t
I would rather talk a school out of this than sell it something it will not use, so here is my honest line.
You need real high availability when the stakes and the load are both genuinely high. High-stakes online assessment, where a failed exam window has academic consequences. Large enrollment, where the peaks are big enough that ordinary hosting cannot absorb them. Accreditation or revenue tied directly to uptime. A hard synchronous calendar, where classes happen at a fixed time and a fixed time only. When several of those are true at once, high availability stops being a luxury and becomes part of doing right by the students.
And you do not need it, or not yet, when the picture is quieter. A small asynchronous cohort that works on its own schedule, with no fixed moment where everyone shows up together, does not have the stampede problem in the first place. Low-stakes coursework, where a student who hits a slow page can come back an hour later with nothing lost, does not carry the same consequence. If that is your program today, the honest advice is to spend the money on the teaching and the content, keep a tested backup, and revisit this when your enrollment or your assessment model changes. It will change, and you can build for it then.
What a newsroom taught me about deadline load
From 2011 to 2013 I ran the eleven-masthead canada.com portal on WordPress VIP. Eleven newsrooms, contributing into one platform, at newspaper scale, on infrastructure built to stay up when a story broke and the traffic arrived all at once.
A newsroom filing on deadline and a class submitting on deadline are the same infrastructure problem wearing different clothes. Both are spiky, deadline-driven load. Both have a moment where a crowd acts together and being down is not an option, because the moment does not wait for you. The discipline you learn running one transfers cleanly to the other: size for the peak and not the average, test the failure paths before the crowd arrives, and treat the integrations and the data as part of the system rather than as someone else’s problem. I ran that discipline for newsrooms. It is the same discipline a school needs, pointed at students instead of stories.
The whole chain, or none of it
If you take one thing from this, take the chain. High availability for a school is not a redundant web server. It is sign-on, student data, content, video, and a restore you have proven, all sized for the worst ten minutes of the busiest night, and it earns its cost only when the stakes and the load are both real. When they are, it is some of the most worthwhile infrastructure a school can build, because it protects the one thing you cannot re-run: a student’s shot at doing the work on time.
If you are standing up or rebuilding a learning platform and you are not sure which side of that line you fall on, that is the conversation to have first, before anyone quotes you a number. Tell me what your busiest night looks like and what happens to a student when it fails, and we can work out honestly how much of this you actually need.
Leave a Reply