I have this concept of rewriting a game engine as a scalable collection of microservices.
It's currently a proof of concept but the main principle lies in each player having their session/connection held and managed by a single container, so containers will scale up and down based on the amount of connected users.
Each player container will speak to multiple other microservices to gather data and perform actions, these services will be static replica's of 2 or 3.
There is one microservice I have in mind which I feel is a bit of bottleneck which I'm currently looking for ways to make more 'scalable' and 'robust'.
This microservice in question is the GameMap service. There will be multiple GameMap services (atleast one service for each uniqe or instanced gamemap). Each map will contain N number of cells and each cell can contain objects with different types / states for example (i.e other playerObjects, ItemObjects)
I would like to be able to have a replica of atleast 2 for each GameMap to instantly flip if one was to for some reason fail and shutdown.. it is important for the users to have a seamless transition between the failing and failover GameMap. To achieve that I need to have consistent / up to date state shared between them.
The need to be able to load balance traffic between the two replica's is a nice to have but not essential.
So far the one potential solution I have come is hazelcast. This will allow me to keep the state of each map cell in a scalable memory data grid (again for robustness and scalability).
I expect that there may be up to 100s of state changes within a gamemap every second and my concern is that it may be too slow and cause huge latency between users.
Has anyone got any hints, suggestions or feedback based on the both scenario or more importantly the usecase of hazelcast here?
P.S. i can upload my very crude connectivity/architect diagram of my game engine as micro services at some point if it helps or if anyone is interested.
It really depends on your requirements, environment etc.
Especially if you want to be HA, you probably want to replicate to different availability zones or potentially different regions and you will be bound by the speed of light (or need to accept there is a chance for data loss). So in other words; the performance is mostly determined by the infrastructure.
But just to give you some ballpark numbers; for a simple read on c5.9xlarge instances on EC between machines in the same low latency group you are looking at 100/200 us. And running a hundreds of thousands of gets second per instance is normally not an issue.
In other words; it is very difficult to say if this is the right approach. Depending on your situation and how important this is, I would take a single slice of your whole system and make some benchmarks to get an impression how well it performs and how well it scales.
But my alarm-bells are going of when I see the combination of micro-service with 'real time' and 'game engine'.