Designing for the spike, not the average

Exam results in Kashmir do not trickle out. A board publishes, word spreads, and within about two minutes essentially every student in the region is on the same page looking for their number. The rest of the week it is quiet.

That shape is the entire engineering problem. Everything else about the platform follows from it.

Why the obvious answer is wrong twice

Size the servers for a normal day and they fall over on the only day anyone judges you on. Nobody remembers the eleven months it was fine.

Size them for the peak and you pay for the peak on the three hundred and sixty days it never arrives, for a platform whose budget is not a large company's.

Both answers are wrong because both assume a single number describes the load. It does not. There are two loads, three orders of magnitude apart, and they need different treatment.

What the traffic is actually made of

Here is the thing that unlocks the whole design: during a spike, almost every request is the same request.

Twenty thousand people are not asking twenty thousand questions. They are all asking for the same result page, published seconds ago, unchanged since. That is not a database problem at all. It is a cache problem wearing a database problem's clothes.

So the read path is cached hard, and the database mostly never sees the traffic. The parts that do scale to zero between events, because between events there is nothing for them to do.

What did not get built, and why

There is no account system. No feed. No personalisation. No recommendations.

Every one of those was considered, and every one adds something that can fail on the day the site cannot afford to fail. A personalised page cannot be served from a shared cache — that is the whole meaning of personalised. Adding it would take the one property the architecture depends on and trade it for a feature nobody asked for.

The product a student wants is a notification when the thing they care about is published, and a page that opens when they tap it. That is small on purpose.

Seven years of running it

It went live in 2019 and I still operate it. That is where the real lessons are, and most of them are about which of my early decisions were wrong.

The one I would emphasise to anyone building for a spike: your monitoring has to survive the event too. Alerting that depends on the same overloaded path tells you nothing precisely when you need it. If the dashboard is down because the site is down, you have two outages and no information.

And rehearse it. A spike you have never simulated is a hypothesis, not a plan. The first real one will find whatever you were wrong about, in front of everybody, at the only moment it matters.