CQRS and Event Sourcing without the pixie dust

Fearing eventual consistency often leads to a worse outcome: eventual inconsistency. Learn a pragmatic approach to building resilient systems that actually work.

#1about 3 minutes

The problem with traditional layered architectures

Traditional layered architectures often evolve into a "big ball of mud" monolith that is difficult to change and maintain.

#2about 3 minutes

Why microservices often become a distributed monolith

Applying monolithic development practices to microservices results in a distributed "big pile of mud" instead of a truly modular system.

#3about 6 minutes

Using events to decouple services in architecture

Events can decouple services by allowing components to publish facts without knowing their consumers, but this alone doesn't solve underlying architectural issues.

#4about 8 minutes

Differentiating event sourcing from event streaming

Event sourcing involves a component using its own past events to make future decisions, unlike event streaming where one component simply consumes another's events.

#5about 4 minutes

Introducing CQRS to solve event sourcing's limitations

CQRS separates the command model for handling changes from the query model for providing current state to address the limitations of pure event sourcing.

#6about 7 minutes

Moving from event-driven to message-driven thinking

A truly message-driven architecture requires discipline and uses distinct message types like commands, events, and queries for different communication intents.

#7about 12 minutes

Demo: Refactoring a monolith into microservices live

A live demonstration shows how an application built with location transparency can be refactored from a monolith into microservices by simply moving code between modules.