Eventuate™ is a platform for developing transactional business applications that use the microservice architecture. Eventuate provides an event-driven programming model for microservices that is based on event sourcing and CQRS.
The benefits of Eventuate include:
- Easy implementation of eventually consistent business transactions that span multiple microservices
- Automatic publishing of events whenever data changes
- Faster and more scalable querying by using CQRS materialized views
- Reliable auditing for all updates
- Built-in support for temporal queries
Eventuate™ Local is the open-source version of Eventuate™. It has the same client-framework API as the SaaS version but a different architecture. It uses a MySQL database to persist events, which guarantees that an application can consistently read its own writes. Eventuate Local tails the MySQL transaction log and publishes events to Apache Kafka, which enables applications to benefit from the Apache Kafka ecosystem including Kafka Streams, etc.
This diagram shows the architecture:
Eventuate Local currently only supports Spring Boot applications but we plan to add support for other frameworks and languages over time.
Learn more about Eventuate Local
To find out more about Eventuate Local:
- Read the overview
- Take a look at the Eventuate example applications, most of which now support both Eventuate SaaS and Eventuate Local
- Read or watch the JavaOne 2016 presentation by Chris Richardson and Kenny Bastani: Handling Eventual Consistency in JVM Microservices with Event Sourcing
- Look at the source code.
Chris, this is very interesting. I have a question on the MoneyTransfer example application. What if there are two Money Transfer requests that are made in quick succession. How do we take care of consistency?
So lets say 1st Request comes in, it saves the command and aggregate and generates the DebitAccount Event, at the same time the second DebitAccount Event (from the second request) is generated on another instance possibly another box. When the EventHandler checks the balance via if and before it debits the account the second instance also does the if check and passes, then we have an issue. How is this handled?
Sanjoy
LikeLike
Glad you like it. Thanks.
Eventuate implements optimistic locking so if two requests simultaneously read-modify-write an Account, the first will succeed and the second will have to retry.
LikeLike