Using MongoDB with microservices

Hey, I’ve been working an online game project for a while. I’m using MongoDB as a primary database. The problem I’m worrying about is game server performance with MongoDB.

Let me explain the project more;
The game servers are using as microservices. Each game server connects to MongoDB directly. Because of the direct connection, I’m worrying about traffic and sync between services(servers).

Example
There is a game character who has 100 gold in-game. Whenever he wants to buy something, the gold decreases and updates his document from MongoDB.

Problems/Questions

  1. Is it good practice to update that much even the game has over a thousand player?

  2. The update operation might be happen anytime. If any of the other servers(the servers not player in) wants to get player document from MongoDB, the document might be not updated.

It might be sound like game system problem but my solution will be depend on MongoDB.

Thanks in advance!

Hi @Duck,

MongoDB can obviously be used for Gaming and for very high write/read workloads. It’s the way you implement for document model (writes by scale of players) and your replication/sharding (distributing your data over multiple servers).

  1. If each player’s gold is in it’s own document (which it should be), then updating 1 document (player’s details) will not affect any other player’s information, and all players can do this simultaneously.
  2. “If any of the other servers(the servers not player in) wants to get player document from MongoDB, the document might be not updated.” --> This depends on your replication process. Each server should be connected to a mongoDB Replica, and your writes must have “majority” concern set. More on this - here.
  3. Don’t have 1 connection of mongodb per player. Route each’s players (client/ui) requests to some backend service sunning on servers and each service might be connected to MongoDB. This will ensure your scalability with any system, not necessarily MongoDB.
  4. Model your data models properly and set your replication/sharding configuration appropriately. You can easily scale. :slight_smile:
1 Like

Thanks for the advices!

I’d want to give more information about current system. Thus, you can understand my situation more.

All of the game servers have only one mongo connection. There won’t be any other connection in same server for mongo.

Whenever a player joins any of the game servers, it gets player document/module from mongodb and cache inside JVM(Java Memory.). If he/she do something that triggers data update, the server update both cache and mongo document. That’s all!

Since this project is new, I do not want to struggle with compilcated packet system across the network and other stuffs related to data and caching(master/slave etc.). If it’s possible, I would want to make the system as simple as possible for now.

Is “majority” feature solve my situation?

So the way I understand is that -

  1. The player can connect to any server.
  2. When player connects, you cache the player details in that particular local server (reads does not go to mongodb further).
  3. Any update player makes, will be an update to their own document and the cache and database would both be updated.

If this is the scenario, then this will work perfectly awesome. Assuming no other player is writing/reading any other player’s information (as writing other player’s document may lead to stale cache for that particular player).

Write concerns are mostly used to ensure that the write operation has been acknowledged by X number of replicas (data bearing nodes) of your mongodb deployment. For simple example, if you are using Atlas, and you are having 3 nodes in your mongodb replica set, “majority” would mean that atleast 2 nodes would reflect the new write that is going to take place, before the update query returns back to your application. This is necessary when multiple players might be reading same information (other players information) at same time.

1 Like

Ah, that’s what I want to do actually.

Actually, from players across the network might change each other documents.
Example A player from server X can send “gold” to another player from server Y. Thus, other servers might update players who are in other server.

For that, I’m using “ChageStream” feature. If any of the documents from “player” collection, the server check if the updated document belongs to players in its server and it it is, the server updates the cache.

In addition, since my project is not that big, I’will be using standalone. Even with standalone mode, should I use “majority” for my writings? An online game doesn’t need to avaiable. Therefore, if my project grows, I’d use “sharding” instead of “replication”.

No need for majority concerns for standalone. Do tell me how your project works out… Cheers…! :smiley:

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.