JENNY BROWN: Critter Junction has been scaling,
and their database model is reaching its limits.
Let's look at how we helped Critter Junction better serve
their users by doing a bit of rearchitecting.
[MUSIC PLAYING]
Building a flexible, scalable database architecture
for a large multiplayer gaming application is no easy task.
The larger a platform is and the more components that
have to interact with each other,
the more tech problems can arise.
Some of the problems that Critter Junction had
to face for their flagship multiplayer game
included handling global consistency,
importing data, batch processing for analytics,
and event streaming.
On top of that, this system had to handle access spikes.
That after-work rush of users logging on is no joke,
and downtime is not an option.
Such a complex problem couldn't be solved with just one tool.
And because Critter Junction had already
broken their application into microservices,
this allowed them to apply the appropriate tools
to each component as needed.
Yup, that means mixing and matching Google Cloud database
options, based on questions like what latency is required?
How much persistent data needs to be supported?
Does it require offline reporting?
Is the data structured or unstructured?
Like we covered last episode, Critter Junction
chose Firestore for their spinoff minigame,
but it's also a natural fit for problems
that need a scalable cloud database
with real-time synchronization and offline support,
like their flagship game.
And with automatic scaling up to 1
million concurrent connections and 10,000 writes per second,
Critter Junction doesn't have to lift a finger
or be concerned with downtime, regardless of usage spikes.
This means Critter Junction's architecture
could use Firestore for the game's front-end services,
like player authorization and profiles,
to store billions of documents with hierarchical world-state
data.
To take care of the game inventory
and other game elements that need global consistency,
like purchase history, Critter Junction
uses Spanner as their main game database.
Since Spanner is a fully managed relational database
that offers unlimited scalability,
strong consistency, and five nines availability,
Spanner provides a globally consistent database
that can track up to petabytes of all these important details
without being a choke point in their architecture.
Spanner supports Critter Junction's usage spikes
without planning or downtime, which
is a relief for data admins and users alike.
And as you can imagine, Critter Junction's game
accesses some data sets more than others--
leaderboards and player profiles, to name a few.
To prevent lag in the UI and maintain a quality user
experience for this frequently used data,
Critter Junction went with Memorystore,
a fully managed service that uses
Redis to store in-memory data, creating
a regional in-memory cache that speeds up access
to that frequently queried data and improves
scale and performance as demand grows.
With Memorystore for Redis, Critter Junction
was able to start small and increase
the size of their instances without downtime
by monitoring usage traffic and simply using the GCP
console to make adjustments.
For Critter Junction's huge analytical workload
and time series data--
that's where Bigtable fits in.
It flips scaling on its head and focuses on connection latency.
While traditional NoSQL databases often
restrict elastic scalability with high management overhead,
Bigtable gave Critter Junction consistent sub-10-millisecond
latency while scaling to match storage needs, with no downtime
during reconfiguration.
And because Critter Junction's game events
were logged into Bigtable, their support experts
could troubleshoot problems directly.
From there, Critter Junction needed a SQL-friendly solution
to analyze player profile and back-end data.
So they used BigQuery, a highly scalable, serverless,
multicloud data warehouse.
BigQuery scalability comes from the vast number
of multitenant resources deployed under the hood,
allowing them to instantly allocate
large chunks for seconds at a time while only billing you
for what you use, to keep costs down.
Critter Junction periodically updates
BigQuery with front-end and back-end data, which
is then run through data analytics pipelines
to identify gameplay mechanics that need improvements.
So there we have it.
Critter Junction used Firestore as a document
store for their front-end services
and real-time game data, Spanner for real-time play data
and purchases, and Memorystore to cache common fetches.
Then Bigtable ingests game event logs
while BigQuery helps their analytics team aggregate data
from all those sources.
Keep in mind, this is just one example
of how to build a heterogeneous storage and analytics
architecture that can span any industry.
And while developing a database architecture that
supports tens of thousands of concurrent players isn't easy,
it is possible.
So stay tuned to learn how Critter Junction continues
to improve the design of their database architecture.
For more on this example architecture,
check out the description below and check out our other series
on databases below.
And remember, always be architecting.
[MUSIC PLAYING]