The Architecture of Scale: Why the Monolith is a liability in the current iGaming

More game launches should be a sign of effective scalability by a supplier. But with each new title adding another layer of testing, deployment and infrastructure complexity, expansion can quickly begin to work against the technology that supports it.

This is the architectural difficulty that RGS suppliers face as portfolios grow into hundreds of games, development teams are working on several products at the same time and operators expect new content to reach the market faster.

For Michał Ochman, CTO and Co-founder of Kalamba Games, here is when the difference between monolithic and microservices architecture becomes a business, rather than a technical discussion.

In a classic monolithic RGS, altering one component forces rebuilding, testing and potentially redeploying a much bigger system, creating dependencies. At scale, that can mean slower releases, more technical debt and infrastructure being scaled for demands that might only affect a single game or service, says Ochman.

Speaking to iGaming Expert, Ochman explains why Kalamba sees microservices as an architectural answer to those pressures, how greater isolation can impact everything from certification to player experience and why breaking a monolith into smaller pieces does not necessarily solve the problem.

Black Box to Framework

Michał Ochman, CTO & Co-founder, Kalamba Games
“The key difference between the two approaches is how much of the RGS needs to move when one component changes,” Ochman said.

“In a Monolith your RGS is a ‘black box’,” he explained. The Game Engine, RNG, Wallet integrations, Promo Tools & Reporting Tools all live in one single deployment.

“If you want to change the paytable on a single fruit slot or you want to create a new report based on updated regulatory requirements, you have to rebuild the whole package.

Most importantly, that may also include evaluating things that are not closely related to the original modification to confirm that something else has not been mistakenly affected.

Microservices try to eliminate those dependencies with a different approach to the RGS.

The RNG can be run as a hardened isolated service, wallet integrations can focus on just authentication and transactions, and the individual game logic can be in its own containers.

“This means we can launch a new game in minutes instead of days, because we are not touching the core infrastructure,” Ochman said. We can also test modifications in isolation and not worry about breaking other components.

When technical debt turns into a business problem

The dilemma for CEOs is, Why fix an architecture that’s already working?

The bigger the content repository, the clearer the answer becomes for Ochman. He said: “In a monolith as your library scales from 10 games to 100 games to 500 games, your ‘technical debt’ scales exponentially. "Every new game makes the system slower and harder to test."

At that point, technical debt is more than an engineering issue. It can start to establish how fast games are getting to operators and how well development resources are being utilized.

“With a microservices model, growth is more or less linear, allowing multiple game studios to build on the same RGS at the same time without seeing or interfering with each other’s code, according to Ochman.

“You don’t have to scale the whole RGS if a game goes viral,” he said. “you can just spin up more instances of that specific game’s logic container.

And that gives suppliers with broad portfolios the ability to target cloud resources to the products that are genuinely driving demand, rather of expanding everything along with them.

“You can save a lot on cloud infrastructure just by scaling what is actually under load,” remarked Ochman.

The distinction that players never see

Players are unlikely to know what architecture is behind the game they have opened in a casino lobby. But the effects they will see.

“Absolutely, but they may not know why,” Ochman stated when asked if the player can feel the change.

“In one monolith, a memory leak in the tournament leaderboard can crash the whole server and boot every player out of their game.

“If the leaderboard service goes down, the player can just keep spinning. The leaderboard may take a minute or two to refresh after it's restarted but the fundamental bet/win cycle is still functioning without interruption.”

Latency is another potential plus point.

Cloud providers have a large number of geographical locations of infrastructure, so that relevant services can be installed closer to the player.

The result: “Faster game loads and shorter game cycles,” said Ochman.

The distributed monolith warning

Yet, simply breaking an RGS into smaller pieces doesn’t automatically mean that a viable microservices architecture is created.

One of the major dangers for companies making the leap, Ochman points out, is the “distributed monolith.”

“That’s when the team breaks the code into 20 pieces, but keeps them so tightly coupled that they still have to deploy them all at once or in a particular order,” he said. “If Service A cannot start without Service B, you just replaced a monolith for a complex nightmare.”

To avoid that, we need a fundamental change in the way services are communicating. Ochman highlights the use of asynchronous and event-driven communication, using technologies such as Kafka.

He said: “Your services shouldn’t ‘call’ each other and wait for an answer; they should ‘emit events’.

In practice, this means that a game service can declare a win and a different service can act on that information independently, rather than having a chain of components waiting for each other.

Could microservices simplify regulation?

At first glance, a more fragmented architecture could seem like just more complexity, with suppliers operating under stringent regulatory and certification criteria.

But Ochman says seclusion might help clarify the process. “In a monolith, if you change the leaderboard table, you’re going to need a full re-certification of the RGS because the code is all mixed together,” he told us.

With microservices, controlled components can be “boxed” instead.

Ochman used the RNG as an example.  If the service has not changed, a supplier can show this by using a cryptographic hash, and provide a mechanism to verify which version is running.

Similarly, separating game maths and logic from presentation might make for cleaner boundaries for what has truly changed.

“We can change the look and feel of a game as much as we want without having to run billions of simulations or needing a four-week audit for the math,” said Ochman.

The essential premise is that constant product development does not necessarily necessitate constant changes of the most sensitive areas of the RGS.

Don’t Just Hire ‘Coders’

But microservices do alter what suppliers expect from their technology staff.

“You have to stop hiring just coders,” said Ochman. Begin employing platform developers. In a monolith you simply check the logs. “In microservices, a single bet may touch five services or 25.”

If something breaks on the way, developers have to establish exactly where it happened.

That also makes API Management a thing. “When you upgrade the Wallet API you don’t accidentally break 200 games that depend on it,” Ochman said.

The emphasis therefore goes to having teams who can design software but also understand the broader platform that the software runs on.

Don’t ‘Big Bang’ the migration

For vendors convinced by the business justification, the next concern is how to migrate off of an existing monolith without affecting the activity it serves.

Ochman has one explicit caveat.

“Never do a Big Bang re-write. It is a never-ending story.

Instead, he recommends the Strangler Fig Pattern, in which the previous architecture is incrementally rebuilt.

“Start with a proxy in front of your monolith,” he said. “Then you select one small, non-critical feature, say Big Win replay service and implement it as a microservice.”

Traffic for that feature can then be redirected to the new service, while the rest of the platform can continue to run on the previous architecture.

Over the next few months you keep “strangling” the monolith, little by bit, until one day there is nothing left of the old code.

Migration is incremental, rather than banking the operation on a single transformation initiative.

The RGS zero latency?

“Microservices are not the end game for Ochman.

“There are two things that will move RGS architecture forward,” he said, “serverless game math and edge computing.”

“Studios aren’t going to be building full ‘servers’ anymore,” he projected. “They will just write the core game logic in Java, Python or TypeScript and upload it to our RGS games platform module. The infrastructure will do the rest.”

The second shift might bring game execution much closer to the players.

“Even today, with microservices, the round trip from a player’s phone to a data center in Frankfurt or Dublin creates a lag that kills the feel of a game,” said Ochman. “This will enable real-time, high-speed multiplayer casino experiences that are not possible today,” he said.