Microservices – Common Patterns
In previous article we saw why should we choose microservices architecture in first place. In this article we will see some most used common patterns we use in microservices architecture.
Some patterns and problems it solves
• Services should communicate with other services using API’s contracts and events.
• Each service should have their own database/ table. Each data should have only one owner service that can modify the data.
• Data validation
• How to handle Transaction ?
• Patterns to join data
Let’s discuss the first two bullet points and check out why we should follow that pattern.
As we discussed in the previous article the whole idea of microservices is to get the ability “to independently develop test and deploy services.” , so that we can scale out with minimum dependency.
In order to support the independent life cycle, we need to make sure that change in one service should not impact other services.
Services should have their own database/tables and each dataset should have only one owner service that can modify it.
If a dataset has two or more services that can modify it, that will mean. that the two services are sharing that data point , Hence are coupled with each other.
For instance, if two services are writing a value to a column which is of type Varchar and one service decides to change it to boolean. This will mean that other services will also need to change.
Therefore we lose our capability to independently develop, test, and deploy the service.
Communicate using API contracts and events
If a serviceA access the database of other serviceB directly that will mean that any change in the database of serviceB can impact the serviceA that is directly accessing the data.
We loose capability to independently deploy the changes and this will need coordination to verify that changes are not impacting any other service.
However, If we access data of other services using API, and if we don’t change the contract, serviceB can change independently without any change in servcieA.
We should be able to change the service without impacting other service.
Monolith has a primary key and foreign key to maintain data constraints and validate the data but in microservices data is distributed across services.
In order to validate the data, you need to have you have custom logic in your application layer.
To join the data, you can fetch data from other services using APIs and join the data in the application layer. For instance, If you need details for all the orders for a given customer.
If performance is in consideration, service can’ maintain read only copy of data. We can return results by easily joining the tables. Moreover, data is synced by consuming events whenever data changes in owner service. Data will be eventually consistent here.
Transaction in microservices is complex. We will discuss the SAGA pattern in the next article.
These are the few most common patterns you will need and use in a microservices architecture. Let me know your thoughts in the comments.
Follow use here.