The life beyond event sourcing: Why building event sourcing strategy is awesome and dangerous

Description

When it comes to building complex systems architectures, teams often begin with strategies such as event drive and, in some cases, even sourcing approaches. What some forget is that details in postproduction might generate more problems than solutions. Biharck Araújo demonstrates problems with projects using event sourcing strategy with real use cases.

Some projects paid insufficient attention to event modeling. It’s remarkable that event sourcing strategy allows you to build a good record of events related to the business. Moreover, it also allows for auditing, monitoring, analytics, machine learning, and a lot of other interesting purposes. In order to access all of those features, the events must represent things that have happened in the desired domain. The majority of the pitfalls come from complex events, more than create, read, update, and delete (CRUD) operations, which in most of the cases are the real issues.

Other projects didn’t acknowledge that events are the primary source of truth. Events are the primary source of truth, but in general, we don’t care so much about either storage strategy or which storage strategy is recommended for each architecture style and system’s design complexity. The first priority must be questions like whether or not to use an eventual consistency, relationship database, in-memory database, etc., since events are not just lost or duplicated in the beginning.

There are also issues with relying on synchronicity, the necessity to normalize projections when using command query responsibility segregation (CQRS), and aggregating boundaries design, which generates huge consequences that might create chaos when refactoring if modeled wrong.