Michael Ploed talks about the distributed data management challenges that arise in a microservices architecture and how they can be solved using an event-driven architecture. Michael describes how event sourcing is a great way to implement an event-driven application. He talks about Command Query Responsibility Segregation (CQRS) and how it's a key part of an architecture based on event sourcing.
Michael Ploed is Principal Consultant at @innoq, founder of @allschools, all out music addict.
This is a one-of-a-kind conference for application developers, solution and data architects: people who develop business applications, create multi-device aware web applications, process vast quantities of enterprise data, design cloud architectures, and manage high performance infrastructure. The sessions are specifically tailored for Developers and Architects using the popular open source Spring IO Projects, Groovy & Grails, Cloud Foundry, RabbitMQ, Redis, Geode, Hadoop and Tomcat technologies. Whether you're building mission-critical web or business applications, crunching huge amounts of distributed data, or designing the next killer cloud native application, SpringOne2GX will keep you up to date with the latest enterprise technology.
wrong label on this one
Re: wrong label on this one
thanks for pointing this out! it's all fixed now.
Solution without compromises around validation
Situation: your event store contains an e-mail address but your read model is not yet synchronized; Two users want to register in about the same time, with the same e-mail address;
The first user got his e-mail address in the event store, and the other one should not get it inside.
Solution: first look in the read model if the e-mail exists and if it does, return "e-mail already exists"; if it doesn't:
iterate backwards the event stream and look if the e-mail address exists in an event.
New problem arises: how far back do you have to go? Solution: as far as your read model has been synchronized.
So to make this work, each time after the read model gets synchronized, insert into the event stream a "marker event" telling you that the read model has been synchronized.
Events which affects two or more aggregates
there is a rule of the tumb to mutate aggregates in separate transactions. if one aggregate during the command issues events which are affects other aggregates and they handled in separate transactions. what happens if some of those transactions fails due to some technical problem or just because those events breaks some aggregate invariants. How those cases are handled.