Microservices: separate db instance vs. separate db server

Question

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.

Answer 1

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.

Answer 2

A general microservice definition is that each service "owns" its data/schema. If one makes a change to the underlying data/schema, only the microservice that owns that data should be affected. Having the data in a separate instance or a separate server meets this definition.

One could even have just one database with different services updating different parts of the database schema, although there could be a greater temptation to cross data boundaries in that scenario. So, it's better to have some sort of physical or logical separation to avoid that when doing a micro-service approach.

Based on how many users or how the usage traffic pattern is will dictate which arrangement works best. For example, if I have an application with just a few thousand users, one database with multiple instances may suffice. If I have several million users, each service might have its own database that can independently scale up or down based load or usage.