When we design microservices architecture, the biggest challenge is how do we manage the data persisted, consistency, availability, scalability when business grows and accuracy at any time.
Unlike the monolithic applications where data is strictly have the ACID properties, microservices need different strategy and design to meet the real need of microservices architecture. The transaction management cannot be guaranteed in microservices architecture considering the decomposed components and number of nodes of applications services running.
So here are recommended database design patterns (solutions to popular problems).
1. Database per service
2. Shared Database
3. SAGA
4. API Composition
5. CQRS
6. Domain Event
7. Event Sourcing
Lets discuss each one of them in detail.
1. Database per services:
If we are on Domain Driven Methodology and all our business design and system design is based on Domain Driven Methodology, then we can prefer this option. Creating own database for each API, so no other services can directly access this database. Only through the API this database can be accessed and data manipulations can be performed.
This is called as Data As Service. Considering the database we wanted to use in enterprise we make decision.
This is not suitable for larger enterprises like Banking and Financial Services, Insurance Companies because they still rely on RDBMS systems and need ACID properties. So they might different strategies.
When we building this Data As a Service, there are other issues design issues need to be assessed example Boundary Context.
No comments:
Post a Comment