Improving Exam Results Systems Performance Under High Load

The Problem

Every year, when official exam results are released, hundreds of thousands of students and parents attempt to check their results within minutes of the announcement. This “sharp traffic spike” pattern commonly causes, in many similar systems:

• Complete outages or severe slowdowns lasting hours
• Repeated connection failures (timeouts, HTTP 500 errors)
• Effective inaccessibility of results for hours, despite each individual result being a small, effectively static piece of data once published

The outcome is a frustrating experience for a large public audience at a socially and emotionally sensitive moment, along with significant public and media pressure on the responsible authority.

Analysis

Based on the common architectural pattern in this class of systems, the root cause is usually an accumulation of several design decisions:

1. Direct database queries per request

No caching layer sits between users and the database. Every “enter your ID number” action triggers a full SQL query, even though results are entirely static once officially published.

2. No content distribution / load-absorption layer (CDN)

All requests hit a single server or a limited server pool directly, with no geographic distribution or intermediary layer absorbing a large share of traffic before it reaches core infrastructure.

3. Architecture built for typical daily load, not exceptional peaks

Government systems are often built and tested for regular daily usage, while the results-announcement moment can represent thousands of times the normal load within just a few minutes.

4. No separation between the “peak window” and normal system operation

There is typically no distinct operational strategy for announcement day versus the rest of the year — the system runs under the same configuration year-round.

Proposed Solution

A phased architectural solution that does not require rebuilding the system from scratch:

1. Redis caching layer

Immediately after results are announced, all results are bulk-loaded into Redis as a key-value map (ID number → result). Every subsequent query is served directly from memory, never touching the database — millisecond response times instead of seconds or full outages.

2. Static snapshot generation via CDN

Since results are immutable once published, small static JSON files can be generated and distributed via a content delivery network (Cloudflare or Azure CDN), serving the vast majority of requests without ever reaching the origin server.

3. Visible queueing experience instead of error pages

Instead of a confusing 500 error page when capacity is exceeded, a clear queueing UX shows users their estimated position — maintaining an acceptable experience even under extreme load.

4. Pre-announcement load testing

Simulating expected load (based on the actual number of registered students for that year) weeks ahead of the real date, rather than discovering weaknesses live on announcement day.

5. Time-boxed auto-scaling

Activating additional compute resources (such as Azure Container Apps or similar auto-scaling groups) only during the hours surrounding the official announcement, then reverting to normal capacity — cost-efficient without compromising performance when it matters most.

Value Delivered

Transforming what could be hours of outages and public frustration into sub-second responses for every individual query — without rebuilding the existing system, but by layering smart engineering on top of current infrastructure.