Scaling a Student Grade Portal from 5,000 to 500,000 Users Without Buying More Servers
Grade portals are a pure read-heavy, eventually-consistent workload that appears in many domains beyond education—tax return status, insurance claim lookup, exam results, any system with a publish-then-flood pattern. The 1,000x spike on a shoestring budget forces engineers to lean on preheating and queuing rather than over-provisioning, and the article's breakdown of which cache patterns actually help versus which are e-commerce cargo-culting is directly transferable.
Student grade portals hit a brutal traffic pattern: near-zero load for months, then a 1,000x spike the moment results are published. Unlike e-commerce flash sales, every student queries a different cache key, so lazy-loading caches fail completely. The core insight is that grades are immutable once published and users will accept a 30-second wait, which opens the door to cache preheating and asynchronous processing.
The architecture walks through five versions. V1 handles 5,000 students with a single Spring Boot instance. V2 adds Redis with mandatory preheating triggered at publish time, plus a query switch that blocks traffic until preheating finishes. V3 layers Caffeine local cache and token-bucket rate limiting for 50,000 students. V4 introduces RabbitMQ peak-shaving and MySQL read/write splitting for 200,000 candidates, where cache misses go to a queue and results arrive via push notification. V5 reaches million-scale with K8s HPA, Sentinel circuit-breaking, and CDN-hosted static queue pages.
Each version calls out which classic cache patterns actually apply to this workload. Distributed locks for cache breakdown are nearly useless when every key is accessed by one student. Bloom filters help against enumeration attacks but add maintenance overhead. The article also covers sharding strategy, warning that sharding by semester creates a hotspot on the latest term while sharding by student ID distributes load evenly.
The article's most valuable contribution is its honesty about which textbook cache patterns don't apply. Most system-design content recites cache breakdown, penetration, and avalanche as a checklist; this one explicitly marks distributed locks as low-priority for the student-facing path and explains why.
Sharding by semester being an anti-pattern is a concrete, non-obvious lesson. New engineers often shard by the most visible dimension (time), not realizing it creates a perfect hotspot on the latest period.
The query-switch pattern—blocking all traffic during preheating—is under-discussed in caching literature. Most guides focus on how to warm caches, not on the fact that the warm-up window itself is a vulnerability that needs gating.
The compliance warning about stale grade data during Sentinel degradation is a rare instance of a technical article flagging a legal risk, not just a performance tradeoff. Many engineers would default to serving cached data without considering accuracy regulations.
The advice to generate queue tokens at the gateway rather than the application layer is a sharp operational insight: if the app is down, the queue page still needs to function, so its backend must live at the edge.