A front-running backend

Blog, News

How moving to a microservice architecture saved us 40% in hosting costs and laid the foundation for our game engine success

At MovieStarPlanet we recently changed our back-end architecture from a classical SQL-based monolith to microservices. Why is that interesting to write a blog post about? Because not only did it reduce our hosting costs, the benefits are a huge part of making our game engine, Nebula, the success we are aiming for. 

If you’re not deeply involved in developing highly available and super scalable back-end solutions, you’ve probably never heard about microservices. Although it’s been a buzzword for some years in the tech industry. 

In the monolithic architecture, MovieStarPlanet had before, all features are built together and hosted together on the same server that reads and writes to a SQL database. The client asks the server for specific data, and the server fetches the data from the database and returns it to the client. It doesn’t matter if it’s requesting your friend list, logging in, or anything else. It’s all handled by the same server.

In a microservice architecture, we split everything horizontally into features that are hosted individually. The client will then ask one service for getting the friend list and another service for getting the inventory and so on. This gives us a lot of flexibility such as:

  • The microservices don’t all have to use SQL databases, which means we are free to choose database tech per service. 
  • We can scale microservices much more efficiently. Some services are heavily used, some more rarely.  Because we can scale much more fine-grained now and only need to scale up the services that are getting the most traffic, we have reduced hosting costs by 40%. 
  • We can now scale much faster, so we don’t end up in situations where our users experience downtime due to rapid incremental load.

    Image credit: https://laptrinhx.com/
    Image credit: https://laptrinhx.com/

In the monolithic approach, all code exists in the same project. This is where the so-called spaghetti code can happen. The code-base grows over time and can become quite overwhelming. In microservices, the code is split into individual projects, which makes it much easier to keep the code clean. The much smaller chunks of code also make it much faster for the developers to get an overview and identify bugs. After introducing microservices we have reduced our time to fix bugs from days to hours. So now our talented backend developers can spend more of their valuable time creating new features rather than fixing bugs.

The last huge benefit is also the one that will bring us smoothly into the future. The tech stack and the architecture we have now are generic enough that all our current and future games can run on the same back-end. Previously we had a huge and expensive monolith for each game, now we have a single one-size-fits-all back-end. This will dramatically reduce our hosting costs when we develop new games in the not-so-far future. Why? Because the base cost will be shared by all games. It also means that time-to-market for new games will be much shorter than previously. And this means lower production costs and it gives us a competitive edge.

It’s been a tough ride and a lot of hard work to bring us where we are today. But it’s definitely worth every drop of sweat. We will soon start marketing MovieStarPlanet2 and BlockStarPlanet and we are very fortunate to be in a position where we are ready to scale and welcome a lot of new players.