It is a challenge to write a simple yet meaningful example application that illustrates how to develop event-driven microservices using the Eventuate platform. That is because the microservices architecture requires you to have at least two services. The Money Transfer application has, for example, three (soon to be at least 4) separate services. Even though it is a great example of how to write event-driven microservices using event sourcing and CQRS it is not the easiest introduction to the topic.
To make the getting started experience easier we have created the Todo List application. This application is a Java and Spring Boot application built using Eventuate™’s Event Sourcing based programming model. The application has a HATEAOS-style REST API for creating, querying, updating and deleting a todo list. The API design is inspired by the Todo backend project. The principle difference is that unlike the original version this API is eventually consistent.
The application has a CQRS-based architecture. Creates, updates and deletes are handled by the command side service, which consists of a Todo Aggregate that is persisted using event sourcing. Queries are handled by the query side service, which maintains a materialized view of the todo list in a SQL database.
There are two versions of the application. The simplest version is a single module Gradle project that builds monolithic version of the application of the API. It is a great way to learn the Eventuate API.
The other version of the application is a multi-module Gradle project, which can be deployed as either a monolith or as two microservices: a command-side service and a query-side service.
Both versions come with a Docker Compose file that can be used to launch the application along with a MySQL database.
To get started take a look at the README.md.
Learn more about Eventuate
To find out more about how you can use the Eventuate platform to build event-driven microservices:
- Read the overview
- Take a look at the example applications
- Watch a presentation on building event-driven microservices
- Signup and start using the platform for free
http://eventuate.io/whyeventsourcing.html you spoke about “In this architecture, requests to update an entity (either an external HTTP request or an event published by another service) are handled by retrieving the entity’s events from the event store, reconstructing the current state of the entity, updating the entity, and saving the new events.” What happens when 2 thread concurrently plan to update the entity, won’t both be operating and replaying stale information and update at the same time events to the store. What is the state of such entity?
LikeLike
Great question. Eventuate uses optimistic locking to handle this scenario. The first attempt to update the entity succeeds. The second attempt will fail because the entity will have changed since it was read.
LikeLike