mongoDB in micro-services structure
It's sensible to think about how to scale your application in future, but you can start with a simpler deployment that can grow with your requirements.


  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.


My recommendation would be to set up a single MongoDB deployment (ideally starting with a replica set or hosted service with high availability &amp; data redundancy):


A single deployment of MongoDB can have multiple databases; a MongoDB deployment per service adds unnecessary admin complexity.
For your use case it sounds reasonable to have a database per service and setup a user per service so actions are limited to direct interaction with the expected database.
A database per service also limits potential impact of administrative actions (eg. a foreground index build) that may create database-level contention.


Later you can scale/tune the deployment starting with options like directoryPerDB (eg. faster storage for some databases) or partitioning your data using sharding.


  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.


This is a more nuanced question as it depends on server resources as well as what those connections are doing and how/if your driver implements connection pooling. Ideally I would load test your actual application and determine how resource usage scales with increased user activity. If you are administering your own MongoDB deployment you should review the production notes and in particular make sure you have your ulimit settings increased appropriately to ensure you don't run out of file descriptors.

If you're concerned about ease of scaling you could also consider a hosted database-as-a-service solution (for example, MongoDB Atlas).


  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?


Sharding is initially enabled at the database level but the partitioning happens at the collection level based on a shard key. You can have a mix of sharded/unsharded databases and sharded/unsharded collections in the same MongoDB deployment.