Databases don’t usually get to change shape mid-flight. Hamieverse’s did — twice — without a single player noticing.
Starting Simple, On Purpose
Pre-Alpha read straight from the database with no caching. It was the right tradeoff for a handful of testers, and it bought us speed when speed was the only thing that mattered.
A Deliberate Optimization, Not a Stopgap
As the player base grew, Alpha introduced a hot/cold table split: live match data routed to a narrow, high-speed table, older matches archived where they’d rarely be queried. This wasn’t a quick patch — it was a considered move that kept gameplay smooth enough to safely add longer match loops and more cards.
Beta: Caching, Replicas & A Pipeline Built to Last
By Beta, Redis sits in front of reads across menus, store inventory, and leaderboards. Read/write replicas keep the primary database lag-free while players check profiles or claim rewards mid-match. And underneath all of it, Prisma acts as a secure pipeline — never generating queries on the fly, always triggering stored procedures behind a stable repository layer.
That last piece is why none of the storage changes above ever broke anything above them. Every caller talks to the same interface. What’s running behind that interface is free to evolve.
This is the third post in our series on engineering Hamieverse. Next: how one generalized schema ended up powering leaderboards, guild rankings, and Faction Wars — without writing new backend code for any of them.
Dive into our complete case study for all the details → Engineering Hamieverse: From Prototype to a Scalable Card Game.