In a scenario with multiple teams, each overseeing a few microservices that collectively create a larger system, and where these services frequently use MongoDB databases, is it advisable for each service to set up and manage its own MongoDB database server?
This approach seems rather complex. Alternatively, what if there's just one server to which each service simply adds their databases? Is this latter approach more aligned with current best practices? Essentially, should each service deploy its own database server, or just contribute their database to a shared server?
BTW: MongoDB is just an example here. It could've been any other data store.
Best Answer
Let's step back for a second and consider why separating the databases is important for a moment. The idea behind this is to reduce the shared dependencies between microservices. This has a number of benefits but I argue that the primary one is simplify the process of evolving a service/application. That is, if you need to make a change to service A, you (ideally) don't need to worry about service B or even think about it. Even if you can't fully achieve this, minimizing cross-service impacts is useful.
Having separate databases, regardless of where they are hosted, is a huge improvement in terms of this goal. However, if we go back to the goal of minimizing dependencies, we must consider the database host as a shared dependency. There are some scenarios and activities that cannot be handled independently in this configuration. The main one that comes to mind is upgrading the database. You can't simply upgrade the database in place without considering both services A and B. If there are different teams managing these two services, they will need to coordinate at some level.
Is this a big enough issue to warrant a separate host for each? It kind of depends on the cost of running multiple databases. If that cost is insignificant, then why not keep them separate? What's the downside? On the other hand, if that (total) cost matters and you don't have strong drivers to push you to separate them, it's unlikely to be a major issue. The upgrade problem has a simple solution: create a new DB host running the new version. Each service can then be moved there (or to another separate database) on their own schedule. As long as each service is agnostic to the presence of other dbs on the host you should retain each service's freedom to evolve independently.