Database Design Patterns in Microservice Architecture
Microservice architecture patterns are software patterns that generate reusable services and enable the rapid scaling of services by ensuring they can easily duplicated and distributed where needed.
There are two main options for organizing the databases when using microservices architecture:
1. Database per service:
Each microservice has its data store. Other services can’t access the data stores that they don’t own.
Benefits:
a- Each database is isolated and doesn’t impact other services. There isn’t a single point of failure in the application.
b- Each database is easier to scale.
c- Can use different database technologies for different microservices. So one service may use an SQL database and another one use a NoSQL database. This allows the most efficient database depending on the requirements.
Drawbacks/challenges:
a- Each microservices can only access its database only. So microservices need communication methods to exchange the data.
b- There is a need for a failure protection mechanism in case the communication fails. Let’s say we send payment requests from service A to service B. Service A awaits the response to perform appropriate action based on the result. During that, service B goes offline. We need to handle the situation and inform service A about the result when B is back online
c- Spanning transactions across microservices can negatively impact consistency and atomicity and also there isn't a simple way to execute queries across multiple databases.
领英推荐
2. Shared database:
A single shared database isn't the standard for microservices architecture. the issue is that microservices using a single shared database lose many of the key benefits of choosing microservice including scalability, robustness, and independence
Benefits:
a- no need to span the transaction over the services.
b- the data is fully constrained and the appropriate radiations are preserved. so the redundancy decreases.
c- can execute complicated queries.
d- no need to exchange data between microservices.
Drawbacks:
a- The database will be a single point of failure.
b- changes related to the database could impact multiple services. so the microservices won't be independent in terms of development and deployment as they connect to the same database.
This pattern could be considered in cases like:
P.S. If you found this helpful or think it might help someone else, do like and repost!
Senior Software Engineer(Mobile iOS, Swift, SwiftUI) | Lead n Learn | Design n Deliver | Tech enthusiast
10 个月One way to minimize the downsides of the first approach is use DB Views or DB warehouses (Denodo can be a good option; combine it with graphql further). It would serve as middle layer and also allow all the micro-services to look at the "Shared Data". If one could implement it exactly as per their requirements it would reduce the Database load and also would reduce the run time of the micro services itself. Second approach is already on a decline as we advance more towards cloud and distributed architecture it only makes more sense to not use it unless one has a very stiff requirement to abide by the rule of strictly "Single source of truth".