Please subscribe to our YouTube channel @ [ Ссылка ]
Like us on Facebook @ [ Ссылка ]
Follow us on Twitter @ [ Ссылка ]

"Every microservice get's its own database and then use Kafka" is a typical and naive advise, when reading about eventsourcing. If you approach this architectural style this way, you will probably have a really awful time ahead.

Eventsourcing and CQRS are two very useful and popular patterns when dealing with data and microservices. We often find in our customer's projects, that both have a severe impact on your future options and the maintainability of your architecture. Presentations and articles on both topics are often superficial and do not tackle real world problems like security and compliance requirements.

This combination of half-knowledge and technical confusion leads to many projects that either refactor back to a 'non-eventsourced' architecture or reduce eventsourcing to a message queue.

In this talk, I will summarize our experience while applying eventsourcing and CQRS accros multiple large financial and insurance companies over the last 5 years. We will cover the Good, the Not so Good, and the 'oh my god...all abandon ships!' when doing eventsourcing in the real world...and see how we solved these issues.

David Schmitz
From Senacor Technologies
Principal architect at Senacor Technologies with a history of + 16 years of working in various projects using a bunch of different stacks and environments.

Current focus is on migrating architectures and organizations to cloud and serverless platforms.

свернуть