How to design databases in microservice architecture
Some guidance on what to think of when designing the databases and the microservices
Designing a monolith database is much different from designing multiple databases in a microservice architecture. As you know, we must have full independence on the different microservices and that also applies on their databases.
A microservice is a design concept that bundles together all services needed to deliver the functionality specified. There are usually one team developing and maintaining each microservice, so communication between teams is important.
No - one database server for all microservices is not correct
If you are used to monolith application it can be tempting to create one (1) database server to manage all the data in the solution. That is not the correct way of implementing microservice architecture. Each microservice should host it's own data in a server that is bundled together with the services for the microservice.
Store data where it belongs
If much of the data belongs in multiple microservices, the design is probably wrong.
It's a common issue that developers that are new to the design concept of microservices create too many service. A common design for a e-commerce solution is to have one microservice for Billing and another for Payment Collection. The Payment Collection microservice usually depends on Billing and Billing depends on knowing when a payment has been done. That's a good reason to have both functionalities in one microservice.
Don’t copy data between different microservices
Never change the data from another microservice directly. Instead use REST calls to the API of the other microservice.
If other microservices are having an interest in the change of state – publish events to let all subscribers getting information about the change. You can either use a PubSub solution from your cloud vendor or use Copyl Integration Platform to report events and subscribe to them in other services.
Expect data to be inconsistent
There is no Foreign Keys connections between databases in different microservices. Presume the data is inconsistent between different systems and manage that. We cannot make isolated transactions over multiple microservices. Create local transactions if needed. Use Saga Management to orchestrate requests, enable error handling and enable rollbacks over multiple microservices.
Database documentation in OpenAPI (e.g. Swagger)
We recommend that the database model is defined together with the api and therefore also enjoy the automatic OpenAPI documentation.
Call in the Cavalry
We are here to help and if you need help designing your microservices we will gladly help you. We have helped many small- and large organizations with implementing microservices.
Please reach out to [email protected] and one of our architects will reply.