How cached snapshots made the leaderboard cheaper to serve

I started with the straightforward version of the leaderboard. Every time someone opened the page, the app asked Supabase for the latest companies, sorted them by Elo rating, and returned the current page. It was easy to understand, and for an MVP it was a good first move.

But once I load tested it, the weakness was obvious. The database was doing the same sorted read again and again, even when the leaderboard had barely changed. At 50 to 1000 concurrent requests, the direct version stayed around 19 to 22 requests per second, and the median latency got painfully high.

So I changed the design. Votes still update ratings immediately through the atomic Postgres function, but the public leaderboard now reads from a cached snapshot. That snapshot refreshes on clean five-minute windows. If someone opens the page at 2:24, they are looking at the 2:20 snapshot, and the next window is 2:25.

I also added a countdown to make that tradeoff visible. I did not want the page to pretend it was live every second when it is actually snapshot-based. When the window is ready, the user can refresh rankings manually. I also avoided auto-refreshing every open tab at the same moment, because that would create a traffic spike for no real product value.

The result was one of those satisfying backend moments where a small architecture change makes the whole thing feel calmer. The cached version handled hundreds of requests per second locally, and median latency dropped by roughly 94 to 96 percent. Local tests are not production truth, but they taught me the right lesson: if a result can be shared safely for a few minutes, do not make the database rebuild it for every visitor.