This blog covers how we built two leaderboards with one system in Hamieverse.
In Pre-Alpha, Hamieverse’s leaderboard read directly from a single, all-time table — simple, but loading every player’s history at once isn’t convenient.
Bounding the Cost
As the player base grew, Alpha capped the display to the top 100, which bounded query costs without touching the architecture underneath.
The Real Investment: A System That Doesn’t Care What It’s Ranking
Beta brought the performance work: time-based partitioning for tables so live queries hit a small active slice, and Redis caching for the most-read top-N players. But the more valuable decision came earlier: designing the system around abstract entity IDs and metrics, rather than hardcoding it to individual players.
That single choice is why guild rankings didn’t need their own backend system when they launched. The same code path that ranks players ranks guilds – the only thing that changes is which entity is being measured.
Cleanup That Runs Itself
Automated server-side season resets archive old partitions and clear the Redis cache together, in one pass – no manual intervention needed between seasons.
This is the fourth post in our series on engineering Hamieverse. Next: how missions became data instead of code, and how we made sure a reward could never be claimed twice.
Don’t want to wait for the rest of the series? The complete Hamieverse case study — every phase and every system — is live now on the Algoryte site. Read it in full → Engineering Hamieverse: From Prototype to a Scalable Card Game.