Microservices Architecture – Where to Store Data

Of your three options, the first (a single, shared database) and the third (a "database service") are the most common.

The first is called an integration database. This is generally not seen as a good solution in a microservice architecture. It does add coupling to your services. It also makes it very easy for one service to simply bypass the other services and query into a database directly. You could lose any kind of data integrity or validation provided by the application level not enforced at the database level.

Your third idea is called an application database. And you're right - it allows you to enforce the loose coupling at the API level between services and allows you to more easily scale services at the database level. It also makes it easier to replace the underlying database technology to something appropriate with each service, just as you can change technology or other implementation details of each service. Very flexible.

However, I'd propose an intermediate solution.

Instead of standing up a database service for every microservice, stand up a schema for every service. If you are using multiple database technologies, you may need to split slightly differently, but the idea would be to minimize the number of database servers that you are running, but make it very easy to split out a service into its own database server if and when it becomes necessary. As long as you only allow a database to access its own schema, you have the advantages of an application database but without the overhead of database servers existing for every application or service.

However, as a solo developer, I would challenge the entire notion of microservices at this point in time - Martin Fowler writes about the Monolith First and the Microservice Premium, Simon Brown talks about modular monoliths, and DHH talks about the Majestic Monolith. I'm not sure how well your monolith is organized, but refactor and organize it. Identify components and make clean separations between them for extracting pieces into a service easily. The same goes for your database structure. Focus on good, clean, component-based architecture that can support refactoring into services. Microservices add a lot of overhead for a single developer to build and support in operations. However, once you actually have a need to scale part of the system, use your monitoring and reporting systems to identify the bottlenecks, extract to a service, and scale as necessary.

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.