A while back I came up with this diagram that explains Eventuate using microservice architecture patterns.
Let’s look at each of the patterns in turn.
A key characteristic of the Microservice Architecture is loose coupling. Services must be loosely coupled from a design-time perspective in order to ensure that teams are loosely coupled and, therefore, productive. Services must also be loosely coupled from a runtime perspective in order to maximize availability. This requirement for loose coupling significantly impacts the database architecture and creates the need for the Database per Service pattern. At a minimum, to avoid design time coupling, services must not share database tables. And, ideally, to reduce runtime coupling, each service should have its own database server.
The Database per Service pattern impacts transaction management and querying. I’ll discuss the issues with queries later, but first let’s look at transaction management.
Some update operations (a.k.a. commands) need to update data in multiple services. Such an operation typically doesn’t use traditional distributed transactions (2PC) since that’s a type of runtime coupling. Instead, a command that spans services must be implemented using the Saga pattern. A saga is a series of local transactions that are coordinated by the participating services exchanging messages.
As I describe in this series of blog posts about sagas there are two types of saga coordination mechanisms: orchestration-based sagas and choreography-based sagas.