Event Sourcing and CQRS — An Alternative to CRUD

you need to know HOW the system reached its current state? Event Sourcing stores a series of events instead of the current state. CQRS separates reads from writes.

Event Sourcing¶

Instead of UPDATE account SET balance = 950 you store an event: AccountDebited(amount=50). Current state = replay of all events. Audit trail for free, time-travel debugging, and the ability to project to different views.

// Order events
OrderCreated { orderId: "123", customerId: "456" }
LineAdded { orderId: "123", productId: "789", qty: 2 }
LineAdded { orderId: "123", productId: "012", qty: 1 }
OrderSubmitted { orderId: "123", timestamp: "2016-11-10T10:30:00Z" }
PaymentReceived { orderId: "123", amount: 1500.00 }
OrderShipped { orderId: "123", trackingNumber: "CZ123456" }

// Current state = replay of these events

CQRS: Command Query Responsibility Segregation¶

Separating the write model (commands) from the read model (queries). The write model is optimised for business logic and validation. The read model is optimised for queries — denormalised, materialised views, search indexes.

When It Makes Sense¶

• Complex domain logic (DDD)
• Audit requirements (finance, healthcare)
• Different read models from the same data (dashboard, report, search)
• Event-driven architecture with Kafka

When Not¶

• Simple CRUD applications — overkill
• Small team without DDD experience
• Systems requiring strong consistency (eventual consistency is a trade-off)

ES/CQRS is a Powerful Pattern for the Right Problems¶

Event Sourcing and CQRS are not a silver bullet. But for systems with complex domains, audit requirements, and event-driven architecture, they are a game changer.