Let's recap the journey of GalaxySurfer, going from a niche game to a viral success.
Initially, Juniper Studios started with a simple, single-server MySQL instance to back their GalaxySurfer game. The studio did not expect that there would be a massive adoption of their game, so this is was perfectly suitable solution to begin with. At the time of release, the studio was not concerned with issues such as backup and replication since this was "just a video game" and only anticipated a small number of users at the outset.
Within months of releasing the game, the user base shot up from hundreds to tens of thousands of simultaneous players. As the demand grew, Juniper could take several steps to help its initially meager database grow with demand:
- Spend time ensuring their database environment and queries were well-optimized
- Scale their server vertically, increasing the CPU, RAM, and Storage specs to meet demand
- Intelligently use partitioning to help with performance and distribute the load across multiple disks
As the user base continued to increase over the coming months into the hundreds of thousands, the strain on the database continued to grow, to the point where even a powerful single database primary was not sufficient. To help with this, Juniper studios had a few options to continue scaling.
- Create one or several read replicas to take some of the SELECT load off the primary, allowing it to handle the write traffic
- Build a cache into their architecture
When implemented correctly, a cache can help reduce the load on a primary and replica server.
Eventually, Juniper Studios' game GalaxySurfer reached viral success and hit over 1 million simultaneous players. Even after adding a cache and multiple replicas, their database needed help. From here, the studio chose to use horizontal scaling techniques with sharding on PlanetScale.
- For their large tables, such as ones for tracking player inventory and direct messages, they used horizontal sharding to spread the rows across multiple physical shards.
- For some of their smaller tables, such as achievements and planets, the either would keep them in one keyspace, or copy these tables to all shards so that separate shards could quickly access them if needed.
With horizontal sharding, Juniper now has a future-proof scaling solution to meet continued success.
Thank you for participating in this scaling course. For more information about databases, MySQL, sharding, and scaling, visit our website and YouTube channel.