Event Sourcing and CQRS in Practice

Append-Only Systems, Projection Engineering, and the Operational Reality of Event-Driven Architecture.

This book targets senior Java developers who understand CRUD systems deeply and have heard event sourcing solves audit logging and temporal queries but have not seen a production implementation. Never explain what a database transaction is. Never define eventual consistency from scratch. The reader ships production Java services. This book shows what changes when the database is an append-only log.

Every chapter uses the same domain: an e-commerce order management platform. Order placement, payment processing, inventory reservation, fulfilment dispatch, and refund handling. Each component surfaces every event sourcing challenge naturally: multi-step workflows requiring sagas, read models serving different query patterns, event schema evolution as the business changes, and storage growth as orders accumulate over years.

Four opinions run through every chapter:

Build it from scratch before using a framework. Every core component, the event store, the aggregate repository, the projection engine, is implemented in plain Java 21 and PostgreSQL before any framework is introduced. An engineer who has written an optimistic concurrency check against an event stream understands immediately why Axon's @Aggregate annotation exists and what it is hiding. One who starts with the annotation does not. Axon Framework is referenced as a production alternative after the internals are established, not as the starting point.

PostgreSQL is the event store. Not EventStoreDB. Not a custom binary format. A PostgreSQL table with an append-only constraint, a stream identifier, a sequence number, and a JSON payload is a correct, production-capable event store for the majority of Java applications. The complexity of a dedicated event store is not justified until throughput or cross-service event subscription requirements exceed what PostgreSQL can provide. The book states this threshold explicitly and defends it.

CQRS without event sourcing is a valid and often better choice. Event sourcing without a genuine need for the audit trail, temporal queries, or event-driven integration is accidental complexity. The book states this plainly in chapter 1 and returns to it in chapter 16. Every chapter that introduces complexity acknowledges the simpler alternative and the condition under which the complexity is justified.

The outbox pattern is non-negotiable for external event publishing. Dual writes between the event store and Kafka are not acceptable. The transactional outbox is the only correct bridge between the write side and the message broker. This is stated in chapter 10 and not revisited as an open question.

These positions are stated in chapter 1 and enforced throughout. They are not hedged without a concrete condition and a decision rule.

This book was generated using AI assistance.