Event Sourcing & CQRS for .NET: Building Production Systems with the Critter Stack

The Pitch Most teams that end up doing CQRS and Event Sourcing get there through pain, not design. A monolith stops scaling. A reporting model gets tangled up with write logic. Nobody trusts the audit trail anymore. The patterns are simple enough to sketch on a whiteboard and deceptively hard to run in production, where projections quietly fall behind, dual writes lose messages, and a retry turns one transient blip into a duplicated side effect three systems away.

Get it right and event-driven architecture is one of the most productive ways to build .NET systems that are both auditable and genuinely decoupled. Get it wrong and it's a distributed monolith with worse debugging tools and none of the upside.

This workshop is taught by the person who built the stack most .NET teams reach for when they commit to this path: Marten for events and documents on Postgres, Wolverine for messaging.

Topics We Can Cover The exact mix on the day depends on the room, but here's the menu we can pull from:

• The Critter Stack: a comprehensive introduction to Marten, Wolverine, and the rest of the ecosystem, covering how the tools work together and where each one fits
• Event Sourcing: designing event-sourced systems, projections, snapshots, versioning, and the common pitfalls teams hit in real-world implementations
• CQRS patterns: Command Query Responsibility Segregation with Wolverine and Marten, from simple to advanced, with practical guidance on when and how to apply them
• Asynchronous messaging: reliable messaging with Wolverine, covering routing, error handling, retries, dead letter queues, and integration with external brokers
• Automated testing: testing strategies for event-sourced and message-driven systems, integration testing with Alba, test-friendly architecture patterns, and TDD approaches
• Production readiness: observability, monitoring with CritterWatch, performance tuning, multi-tenancy, and operational best practices for Critter Stack applications

Who Should Attend

• .NET teams evaluating whether Event Sourcing and CQRS are the right call for a system they're about to build
• Teams already running it who've hit real production pain (lagging projections, brittle tests, no visibility into what's actually happening) and want to fix the foundations
• Architects who want a working mental model of this stack before they commit a team to it for the next three years