When the 4 P.M. School Bell Makes the Servers Groan — Heavy Analysis Modules and Designing for Spare Capacity

When you run a service for schools, the traffic waves are genuinely extreme.

Especially after school. The instant the bell rings, requests spike by the second.

It’s quiet all day, then the moment the clock crosses 4 p.m., users come flooding in. The same thing happens right at the start of events — the access graph goes almost vertical.

For an old-school web system, this might have been brushed off as “a bit slow today.” But what we were handling this time was a little different.

Behind the scenes was an AI-powered data analysis module — and a fairly heavy one, built on the assumption of running as a Docker container.

”Just Scale Out with Auto Scaling” Doesn’t Catch Up

At first, we just used AWS Auto Scaling the standard way.

When load goes up, add instances. The classic cloud playbook.

But reality wasn’t that clean.

This analysis module is heavy to start up.

Bring up the Docker container, initialize internal libraries, load the analysis data — only then is it actually ready to process.

It doesn’t finish in a few seconds.

By the time the load balancer detects the spike and starts saying “okay, adding instances,” the peak has already arrived.

In other words,

“By the time it scales up, it’s already too late.”

We Tried Lambda Too

Of course we considered a Lambda setup.

But cutting to the conclusion — it was rough.

The reason is simple: this module wasn’t “serverless-friendly.”

• Heavy initial loading
• Large memory footprint
• Long startup time
• Dependencies on local modules

For a lightweight API, Lambda is genuinely beautiful. But the moment you put a heavy analysis workload on top of it, the design philosophy stops fitting.

Especially when real-time responsiveness matters, “waiting on a cold start” is brutal.

In the end, we came back to a long-running, server-based setup.

The Final Answer Turned Out Pretty Old-School

After trying all sorts of things, the final conclusion was simple.

“Spin up servers with margin, before the peak arrives.”

That’s it.

If traffic surges after school, have everything already up and running by around 3:30 p.m.

Analysis modules already loaded. Ready to process at any moment.

In short, “pre-warming.”

And here’s the interesting part: even after traffic calmed down a little past 4 p.m., we didn’t immediately reduce the number of instances.

School traffic is hard to read. Is it after club activities? Before cram school? An event? Another wave can hit out of nowhere.

So even if it looks a bit wasteful, we keep the surplus servers running for a while.

As 5 p.m. and 6 p.m. roll around, we finally start scaling down gradually.

Of course it’s not manual — we set a schedule. But schedules don’t handle things like summer vacation, so on weekdays we just hard-code “this many servers in this time slot.”

From a cloud purist’s perspective, this looks inefficient. But from a practitioner’s gut feel,

“Rushing the decision to scale down is the dangerous one.”

That was the real lesson.

The “Can You Really Afford to Run All That Constantly?” Problem

Of course people ask.

“You don’t even get that much traffic normally — why are you running so many servers?”

Honestly, fair question.

But the loss when the service goes down was bigger.

Especially for school-facing services, usage timing is concentrated. Making users wait at that moment instantly turns into complaints.

So we ended up with something like:

• A baseline of instances running 24/7
• Extra capacity only during peak time slots

Even at midnight we keep multiple instances up, just in case.

The cloud ideal is often described as “use it only when you need it.”

But on the ground,

“Prepare before you need it.”

And further,

“Even past the peak, keep some spare capacity for a while.”

is sometimes the right answer. This isn’t sour grapes!

Postscript

As an engineer, I dream of a setup that scales up and down smoothly and automatically.

But the real world doesn’t quite work that way.

Especially once you start handling “heavy things,” the endgame turns surprisingly physical.

Stack servers with margin. Boot them up ahead of time. Keep spare capacity even after the peak.

Before I knew it, every day at 3:30 p.m., I was opening the AWS console and taking attendance.

“EC2-01, up and running.” “EC2-02, up and running.” “Analysis module, loaded…”

After harnessing the latest cloud technology, I had somehow become a homeroom teacher working to the rhythm of the school bell.

What was “evolution,” again?