Asynchronous microservices
Why microservices? They enable faster innovation.
Businesses must innovate at a much faster rate to stay ahead of the competition. They must significantly improve how they develop and deploy the software that is the foundation for innovation.
Not only must businesses adopt agile practices and deploy on the cloud but they must also replace their large, cumbersome monolithic applications with microservices.
The problem with microservices: distributed data management
Each service has its own database
In order to ensure services are loosely coupled, each service has its own private database. As a result, when developing microservices you must tackle the problem of distributed data management.
Maintaining data consistency is a challenge
You must implement business transactions that span services but two-phase commit (2PC) is rarely an option.
Querying is a challenge
You must implement queries that retrieve data from multiple services.
Using an asynchronous, microservice architecture.
For most applications, the way to make microservices work and to manage distributed data successfully is to use sagas and CQRS views. In such an architecture, services communicate asynchronously using domain events, and command/reply messages.
Using sagas to maintain data consistency
Sagas are a transaction model for the microservice architecture. A saga is a sequence of local transactions. Each local transaction updates the data in one service and sends a message/event that triggers the next transaction.
Using CQRS views
Command Query Responsibility Segregation (CQRS) views are a way to implement queries that span services in a microservice architecture. A CQRS view is a replica of data from one or more services that is optimized for a particular set of queries. The service that maintains the view does so by subscribing to domain events. Whenever a service, updates its data it publishes a domain event.
The problem of atomically updating the database and publishing messages
You can use an asynchronous architecture to solve the distributed data management challenges in a microservices architecture. However, one major challenge with implementing an asynchronous architecture is atomically updating the database and sending a message.
Consider, for example, the Create Order use case.
The service that implements this use case must perform two operations: insert a row into the ORDER table and publish an OrderCreated event.
It is essential that both operations are done atomically.
If only one operation happened because of a failure then the system would behave incorrectly.
The standard way to atomically update state and publish a message is to use a distributed transaction involving a database and a message broker. However, for the reasons described earlier this is exactly what we do not want to do.
About Eventuate
Eventuate provides two solutions to this problem:
- Use Eventuate Tram for JDBC/JPA-based applications
- Use Event Sourcing with Eventuate Local