Microservices Architecture – Single Database or Instance for Each Service?

Architecturedatabasemicroservicesservice

I understand that a each service in a microservice architecture should have its own database. However, by having its own database, does it actually mean simply having another database within the same database instance or literally having another database instance?

By this, I don't mean sharing of databases, which is a no-no, but rather the database instance.

For example, if I were using AWS and have 3 services, do I create 3 databases for each service on a single RDS instance or do I create 3 RDS instances each containing a database which is used independently by each of the 3 services?

If using multiple databases on a single RDS instance is a better idea, will it defeat the purpose of having independent services because for:

  1. The RDS instance's resource will be shared amongst services. Will Service A which may have heavy database usage at a particular time impact Service B which uses a different database but on the same RDS instance?

  2. All services will be dependent on the database version on that RDS instance.

Best Answer

It really depends on your scalability requirements, and how/if your microservice instances need to cooperate to provide a single result. It helps to know what the trade-offs are:

Keeping it all in one database

  • Easier configuration
  • No coordination or communication with other instances of your service needed
  • Easier to discover your full dataset
  • System performance limited by database performance

Keeping the databases separate

  • The full answer for a request may be spread across microservice instances
  • In that case you have increased communication and negotiation to resolve the request
  • Handling data when you loose that microservice node (even when the database is still up, you can't get at it until a new one with the right configuration is stood back up)
  • Increased configuration complexity

What's the problem you are solving?

In some cases, you are only worried about ephemeral data. If the database goes down, it's no big issue. In those cases you might not even need a database to begin with. Just keep it all in memory and make things blazingly fast. This is the easiest solution to work with.

In other cases, you need the data integrity, but your database is capable of expanding it's capacity based on the number of nodes it has. In this case, a single database is probably more than sufficient, and managing it's responsiveness independently is the right answer.

There are a number of cases in between. For example, you might have databases that are regionally specific, so for each instance of your service in a different region you have a separate database. Typically sharding databases don't do well across regions, so this is a way to localize the data a bit and control coordination yourself.

Doctrine and Reality

I've read a number of articles about microservices and how modular they should be. The recommendations range from keeping the front end, microservice, and data tier as a whole unit to sharing database and/or front-end code for all instances. Usually, more isolation provides the greatest scalability, but it comes at the cost of increased complexity.

If your microservice is calculation heavy, it makes sense to allow the number of those microservices scale as needed--sharing the database or even front end code doesn't hurt or hinder this approach.

The reality is that the specific needs of your project are going to need a different set of compromises to get work done in a timely fashion and handle the system load you are measuring (plus a little more). Consider the fully isolated front-end, microsrervice, and data tier trio to be the lofty goal. The more demand on your system, the closer to that goal you will likely need to be. We aren't all [insert name of highly successful web entity here], and they didn't start out where they are now. Sometimes you just need to start out with a less than perfect situation, and be happy with that.

Related Topic