Event Sourcing with Shawn McCool

16 snips

Jan 16, 2026

In this session, Shawn McCool, an experienced software engineer and domain modeling advocate, dives into the transformative world of event sourcing. He shares his journey from discovering domain events while working on Laravel.io to creating the Event Sourcery course. Shawn explains the key differences between event sourcing and CRUD, while discussing the nuances of CQRS and eventual consistency. He emphasizes the importance of modeling intent and context with events and advocates for short-lived aggregates to simplify versioning and retention challenges.

Ask episode

AI Snips

Chapters

Books

Transcript

Episode notes

ADVICE

Design For Eventual Consistency

Expect eventual consistency when projections are updated asynchronously and design UIs and SLAs around that delay.
Use patterns to reduce delay or provide immediate feedback where UX requires it.

INSIGHT

Avoid Locking Everything In One Transaction

Many systems overuse synchronous transactions for convenience, creating coupling and operational fragility.
Decoupling via events improves reliability by isolating failures to subsystems instead of the core flow.

ADVICE

Test By Given-When-Then With Events

Test event-sourced behavior with given-when-then using events as inputs and expected events as outputs.
Treat events as plain data structures and assert on emitted events rather than internals.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

Shawn McCool returns to the podcast to explore event sourcing - a pattern that fundamentally changed how he thinks about modeling software systems.

We start by tracing Shawn’s journey into event sourcing, beginning with his work on Laravel.io around 2012 when a friend introduced him to domain events. This discovery led him deeper into the DDD community and eventually to creating Event Sourcery, a free video course on domain modeling and event sourcing. Shawn shares how working with event sourcing broke him out of the “way we’ve always done it” mindset.

The conversation covers the core concepts - what event sourcing actually means (using events as the source of your model state), how it differs from event streaming and event-driven architectures, and when you might choose this approach. We explore the relationship between event sourcing and CQRS, discussing how separating read and write models enables independent evolution and scaling, while acknowledging the trade-offs around eventual consistency.

Topics include:

What event sourcing means: events as the core of your model state
The distinction between event sourcing, event streaming, and event-driven architectures
Domain events versus CRUD: capturing intent and context
CQRS: separating decision-making models from read models
Eventual consistency: trade-offs between reliability and immediate feedback
Synchronous versus asynchronous projections
Why DDD isn’t a specific methodology but a pursuit of understanding
Aggregates as lifecycles, not nouns - designing for short-lived event streams
The bank account anti-pattern: why long-running aggregates are problematic
Testing event sourced systems: given-when-then with events
Projections as pure, side-effect-free transformations
Versioning strategies and avoiding the pain of long-lived aggregates
GDPR and data retention: designing systems that don’t need to keep data forever
Implementation approaches: relational databases versus dedicated event stores
Rolling your own versus using frameworks like EventSauce or Marten

Shawn emphasizes how building systems around short-lived aggregates - where event streams naturally terminate - eliminates entire classes of versioning and data retention problems. He shares insights from his work at a payment processing company, where the system is designed so that event streams exhaust within 30 minutes, making evolution and versioning remarkably straightforward.

Throughout the conversation, Shawn demonstrates how stepping away from noun-centric thinking and embracing events as the core building block leads to systems that are easier to understand, test, and evolve.

Show Links