<\/p>\n
1. Database per Service<\/strong><\/h5>\nIn 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.<\/p>\n
Therefore, the database for that service is essentially part of the implementation of that microservice and thus cannot be accessed by external services.<\/p>\n
Ways to keep a microservice’s data private includes:<\/p>\n
\n- Private-tables-per-service<\/li>\n
- Schema-per-service<\/li>\n
- Database-server-per-service<\/li>\n<\/ul>\n
Benefits of Database-per-service<\/strong><\/p>\n\n- Ensures loose-coupling between the services<\/li>\n
- Different service can used a suitable database based on it’s needs<\/li>\n<\/ul>\n
Some Challenges of Database-per-service<\/strong><\/p>\n\n- Some complexity due to creating transactions that span multiple services<\/li>\n
- Several join queries has to be written<\/li>\n
- Hard to cordinate multiple SQL and NoSQL databases<\/li>\n<\/ul>\n
<\/p>\n
2. Shared database<\/strong><\/h5>\nThe shared-database pattern\u00a0 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.<\/p>\n
Benefits of Shared Database<\/strong><\/p>\n\n- Use of ACID transaction to enforce consistency is very clear and straighforward<\/li>\n
- It is easier to implement a single database<\/li>\n<\/ul>\n
Challenges of Shared Database<\/strong><\/p>\n\n- Just one database could not fill the data requirements of all the services<\/li>\n
- Additional coordination during development time between different teams working on different services as they need to access the same data storage<\/li>\n
- Runtime couple could impede performance<\/li>\n<\/ul>\n
<\/p>\n
3. Saga\u00a0<\/strong><\/h5>\nA saga in defined as as sequence of local transactions. In this case, these are transactions that span multiple services. In\u00a0 a saga, each local transaction executes on a database, then publishes a message\/event that triggers the next local transaction in the sequence.<\/p>\n
If however, one transaction fails in the saga, then a series of\u00a0 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.<\/p>\n![\"How](\"https:\/\/www.kindsonthegenius.com\/wp-content\/uploads\/2020\/09\/Saga-1024x538.jpg\")
<\/a>How Saga Works<\/figcaption><\/figure>\nBenefits of Saga<\/strong><\/p>\nIt allows an application to maintain consistency in its data across multiple services without having to use distributed transactions<\/p>\n
<\/p>\n
Challenges of Saga<\/strong><\/p>\nHas a complex programming model<\/p>\n
<\/p>\n
<\/p>\n
4. API Composition<\/strong><\/h5>\nThis is a way to implement queries that access data across multiple services.<\/p>\n
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.<\/p>\n![\"API](\"https:\/\/www.kindsonthegenius.com\/wp-content\/uploads\/2020\/09\/API-Composer-1024x561.jpg\")
<\/a>API Composer<\/figcaption><\/figure>\n <\/p>\n
Benefits of API Composer<\/strong><\/p>\nStraightforward way of querying data across services<\/p>\n
<\/p>\n
Challenges of API Composer<\/strong><\/p>\nSome queries may perform inefficiently due to joining large resultsets.<\/p>\n
<\/p>\n
5. CQRS<\/strong><\/h5>\nCQRS stands for Command Query Responsibility Segregation.<\/p>\n
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\u00a0 by subscribing to the domain events emitted by the service that owns the data.<\/p>\n![\"Command](\"https:\/\/www.kindsonthegenius.com\/wp-content\/uploads\/2020\/09\/Command-Query-REquest-Segregation-1024x916.jpg\")
<\/a>Command Query Request Segregation<\/figcaption><\/figure>\nBenefits of CQRS<\/strong><\/p>\n\n- Has support for multiple denormalized views which has good performance and are scalable as well<\/li>\n
- Separation of Concerns is improved due to simpler command and query models<\/li>\n
- Can be used in an event sourced design<\/li>\n<\/ul>\n
Challenges of CQRS<\/strong><\/p>\n\n- Complexity is increased<\/li>\n
- Possible code duplication<\/li>\n<\/ul>\n
<\/p>\n
6. Domain event<\/strong><\/h5>\nIn 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.<\/p>\n
Benefits and challenges are similar to Command Query Request Segregation<\/p>\n
<\/p>\n
7. Event sourcing<\/strong><\/h5>\nIn this pattern, the state of the business entity such as Patient or Admission\u00a0 is persisted as a sequence of state-changing events.<\/p>\n
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<\/p>\n
Benefits of Database-per-service<\/strong><\/p>\n Some Challenges of Database-per-service<\/strong><\/p>\n <\/p>\n The shared-database pattern\u00a0 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.<\/p>\n Benefits of Shared Database<\/strong><\/p>\n Challenges of Shared Database<\/strong><\/p>\n <\/p>\n A saga in defined as as sequence of local transactions. In this case, these are transactions that span multiple services. In\u00a0 a saga, each local transaction executes on a database, then publishes a message\/event that triggers the next local transaction in the sequence.<\/p>\n If however, one transaction fails in the saga, then a series of\u00a0 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.<\/p>\n Benefits of Saga<\/strong><\/p>\n It allows an application to maintain consistency in its data across multiple services without having to use distributed transactions<\/p>\n <\/p>\n Challenges of Saga<\/strong><\/p>\n Has a complex programming model<\/p>\n <\/p>\n <\/p>\n This is a way to implement queries that access data across multiple services.<\/p>\n 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.<\/p>\n <\/p>\n Benefits of API Composer<\/strong><\/p>\n Straightforward way of querying data across services<\/p>\n <\/p>\n Challenges of API Composer<\/strong><\/p>\n Some queries may perform inefficiently due to joining large resultsets.<\/p>\n <\/p>\n CQRS stands for Command Query Responsibility Segregation.<\/p>\n 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\u00a0 by subscribing to the domain events emitted by the service that owns the data.<\/p>\n Benefits of CQRS<\/strong><\/p>\n Challenges of CQRS<\/strong><\/p>\n <\/p>\n 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.<\/p>\n Benefits and challenges are similar to Command Query Request Segregation<\/p>\n <\/p>\n In this pattern, the state of the business entity such as Patient or Admission\u00a0 is persisted as a sequence of state-changing events.<\/p>\n 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<\/p>\n\n
\n
2. Shared database<\/strong><\/h5>\n
\n
\n
3. Saga\u00a0<\/strong><\/h5>\n
<\/a>4. API Composition<\/strong><\/h5>\n
<\/a>5. CQRS<\/strong><\/h5>\n
<\/a>\n
\n
6. Domain event<\/strong><\/h5>\n
7. Event sourcing<\/strong><\/h5>\n
![\"\"](\"https:\/\/www.kindsonthegenius.com\/wp-content\/uploads\/2020\/09\/Event-Sourcing-300x276.jpg\")
<\/a><\/p>\n