by We would learn about 7 database patterns for Microservices. The include:
1. Database per Service
In this pattern, the microservice’s persistent data are kept private to that service and is can only be accessed through its API. A transaction by a service involves only it’s database.
Therefore, the database for that service is essentially part of the implementation of that microservice and thus cannot be accessed by external services.
Ways to keep a microservice’s data private includes:
- Private-tables-per-service
- Schema-per-service
- Database-server-per-service
Benefits of Database-per-service
- Ensures loose-coupling between the services
- Different service can used a suitable database based on it’s needs
Some Challenges of Database-per-service
- Some complexity due to creating transactions that span multiple services
- Several join queries has to be written
- Hard to cordinate multiple SQL and NoSQL databases
2. Shared database
The shared-database pattern allows different services to access the same database. The approach is to use a single database that is shared by multiple services. Thus each service can freely access the data that is owned by other services.
Benefits of Shared Database
- Use of ACID transaction to enforce consistency is very clear and straighforward
- It is easier to implement a single database
Challenges of Shared Database
- Just one database could not fill the data requirements of all the services
- Additional coordination during development time between different teams working on different services as they need to access the same data storage
- Runtime couple could impede performance
3. Saga
A saga in defined as as sequence of local transactions. In this case, these are transactions that span multiple services. In a saga, each local transaction executes on a database, then publishes a message/event that triggers the next local transaction in the sequence.
If however, one transaction fails in the saga, then a series of compensating transactions in executed to rollback the changes made by the preceding transactions. This is illustrated in the figure below. The Patient service holds information about patients admission into a hospital while the Patient service holds the patient’s details.
Benefits of Saga
It allows an application to maintain consistency in its data across multiple services without having to use distributed transactions
Challenges of Saga
Has a complex programming model
4. API Composition
This is a way to implement queries that access data across multiple services.
The API Composition is achieved by creating an API Composer (which could be another service) that invokes that services that owns the data. Then it performs joins of the results in-memory. This is illustrated below.
Benefits of API Composer
Straightforward way of querying data across services
Challenges of API Composer
Some queries may perform inefficiently due to joining large resultsets.
5. CQRS
CQRS stands for Command Query Responsibility Segregation.
In this pattern, we define a view database. This is a read-only copy of the database that is made to support the particular query. So the application maintains this copy up to date by subscribing to the domain events emitted by the service that owns the data.
Benefits of CQRS
- Has support for multiple denormalized views which has good performance and are scalable as well
- Separation of Concerns is improved due to simpler command and query models
- Can be used in an event sourced design
Challenges of CQRS
- Complexity is increased
- Possible code duplication
6. Domain event
In this pattern, business logic is organized as a collection of domain-driven-design(ddd) modules. These module emit domain events anytime they are created or updated. The service then published these events so that the can be consumed by other microservices.
Benefits and challenges are similar to Command Query Request Segregation
7. Event sourcing
In this pattern, the state of the business entity such as Patient or Admission is persisted as a sequence of state-changing events.
Each time the state of a business object changes, a new event is added to the queue of events. In this way atomicity can be guaranteed. The figure below illustrates Event sourcing
Benefits of Event Sourcing
- It ensures that events are reliably published each time there is a state change
- It avoids object-relational inefficiencies since events rather than domains are persisted
- It provides an audit log of changes made to business entities
- Allows for implementation of temporal queries
- Supports loose-coupling of business entities
Challenges of Event Sourcing
- It is an unfamiliar programming model and therefore has some learning curve
- Event stores could be inherently difficult to query
