CQRS and Event Sourcing are powerful patterns often mentioned together. Understanding what each brings separately helps avoid the over-engineering of systematic adoption.
CQRS (Command Query Responsibility Segregation) separates read operations (queries) from write operations (commands) using distinct models. The main advantage is independent optimization of each side: the read model can be denormalized for performance, the write model can be rigorously consistent. On systems with very asymmetric read/write ratios (e-commerce type: many reads, few writes), the performance gains are significant.
Event Sourcing goes further: instead of storing the current state of an entity, you store the sequence of events that led to that state. An e-commerce order doesn't have a status field that changes — it has a list of events: OrderCreated, PaymentReceived, ItemsShipped. The current state is recalculated by replaying these events. This brings a native audit trail, time-travel debugging capability, and total change traceability.
These patterns are often presented together because CQRS naturally facilitates Event Sourcing implementation. But they're independent and each can be adopted alone. The usual caveat applies: operational complexity is high. Eventual consistency, managing event schema migrations, efficient event store storage — these are real challenges. Reserve for high-value business domains where auditability and scalability justify the investment.
→ See also: Event-driven architecture · Domain-Driven Design