I'm building a game that have micro-services structure using docker.
The way i started to build my services is having a mongoDB instance to each service, so having OneToOne service to mongoDB instance,
Resources ---> resourcesDB (mongoDB instance 1) Chat ---> chatDB (mongoDB instance 2) Buildings ---> buildingsDB (mongoDB instance 3) Battle ---> battleDB (mongoDB instance 4) ...
This really made sense at the beginning as those services for example have nothing in common and don't need have a connection to the same mongo instance, and when they do have something in common (building <-> resources) they just send a call to the needed service and that handles the rest (update his DB).
But i starting to think that this is not the right approach because of couple of things:
1 - resourcesDB for example have only 2 collections,
Logs ---> logging every resources change (building built, war lost etc.) Resources ---> 1 document per user holding how much he have.
meaning that this DB will not hold any huge data (logging will be deleted after some time), so setting an instance just for those 2 collections is looking like a huge over kill, even if this instance will not have its own server and will share server with the service.
2 - maintaining and doing backups will require some extra work that I'm not sure that its needed in my case.
Each of the service will update his DB quite often, resource is doing calculation every second to see how much each user have, so it will update the db
'users amount' per second, aside with the rest of the requests like build a building (reduce resources) and other updates,
Chat service will update the DB every private message or chat message, Battle service will update troops place and stats and more stuff every second for each battle that is going on.
I'm thinking to chance that structure to one of the next:
maybe have only 1 instance of database with separated DB, so each service will connect to a separated database, but i read that it will still be a hassle to maintain backups of the DB's and scaling.
have 1 database, and have all the collections in it, every collection will be accessed by a different service and will never be accessed by 2, so i have nothing to worry about 2 service changing same collection.
leave it as it is, and go with many instances of mongoDB
few questions about the methods above:
what should i choose? having 1 database sounds good as it will save me a lot of resources and will make my life easier, but separating the services to many database sound logic to me as one service don't need to see collections or be able to access a collection that have nothing to do with his job.
I'm not sure how mongoDB handle many connections to the same instance, or to same database, as you can see it might get a lot of calls in a second even if i have pretty low amount of users.
I read about mongo Sharding, from what i understood it happens per database and not on the instance level, that's why i'm thinking about the 1 database option, as it quite useful in my case, am i right?