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

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

An AI agent is the most demanding user your framework has ever had, and by far the most honest. It can't ask a coworker, can't lurk in your Discord, can't intuit that "it just works that way." Every single thing it gets wrong is something your framework failed to communicate.

For the past year the Critter Stack team has been adapting to our new AI world order. This is our report of all the spaghetti we've thrown up against the wall. From leaning even harder into our already terse coding style that saves on token usage, to curating AI Skills files to make AI agents lean into that style, to building reflective capabilities into every part of our system so AI agents have a mix of command line diagnostics or MCP tools to understand how a Critter Stack application is configured and behaving. We'll also talk about how we've tried to build AI friendly test harnesses that allow an AI tool insight to a system under test -- especially for the type of Event Driven Architecture that our tools specialize in.

An AI agent is the most demanding user your framework has ever had, and by far the most honest. It can't ask a coworker, can't lurk in your Discord, can't intuit that "it just works that way." Every single thing it gets wrong is something your framework failed to communicate.

For the past year the Critter Stack team has been adapting to our new AI world order. This is our report of all the spaghetti we've thrown up against the wall. From leaning even harder into our already terse coding style that saves on token usage, to curating AI Skills files to make AI agents lean into that style, to building reflective capabilities into every part of our system so AI agents have a mix of command line diagnostics or MCP tools to understand how a Critter Stack application is configured and behaving. We'll also talk about how we've tried to build AI friendly test harnesses that allow an AI tool insight to a system under test -- especially for the type of Event Driven Architecture that our tools specialize in.