rasmus
commented
6 years ago Hi
EventFlow handles concurrency using optimistic concurrency within each aggregate root. This is done using the aggregate sequence numbers of the aggregate events. If a collision is detected, the command is retried on the updated aggregate root as it might still be a valid operation, e.g. the order of changing title and sub-title of a book doesn't really matter.
As for handling concurrency for two aggregates, between bounded context or even within the same instance is something else. We typically try to design our applications in a way that removes the need.
The typical text book example would be something like this
With hard concurrency 1) User A and B has 100$ in their shared account 2.a) User A pays a bill for 100$ 2.b) At the same time user B pays another bill using the same account for 80$ 2) One of the users is denied
Alternative 1) User A and B has 100$ in their shared account 2.a) User A pays a bill for 100$ 2.b) At the same time user B pays another bill using the same account for 80$ 3) Users A and B now have -60$ on their account and back starts to collect interests
I know its a very basic example, but I hope it clarifies it up a bit. In your case deleting a user will ripple through different systems. Consider if this really needs to be instantaneous.
A few other notes
- Round robin load balance and each service instance has to be stateless
- In our setup every direct interaction between services is some form of HTTP REST and there isn't anything that gives hits about what kind of technology that's used within a service
- Eventually consistence is key. Try to figure our if everything really has to be aligned within a millisecond. Typically "instantaneous" for a developer is within a few milliseconds, but for a customer its seconds or even minutes
- Typically we run a minimum of three instances of an application but sometimes around twenty as well
- We never share DB, event store, or even read stores between services. Everything is exposed using HTTP services only (and some RabbitMQ)
- We only use CQRS, DDD and ES for our key components, almost everything else are basic CRUD services at their core
Hope I got it all
mattgi
In considering just the write side of the equation, I am wondering how one deals with concurrency across services.. also hoping for simple guidance on how to structure/host EventFlow across multiple domain driven micro services.
For the purpose of the question, here is what I assume to be a common requirement:
Two micro services, separated by bounded contexts.. Item Service deals with Items, User Service deals with Users. An Event in one may impact another (e.g. Deleting a User would mean the Item would also need to reflect that it no longer has an Owner, etc.).
Questions:
Are people typically running multiple instances of the same service in production? Am really curious on the architecture and design of full, production hardened, implementations of EventFlow to be sure I'm heading down the right path.