Event sourcing preserves changes as an ordered event history instead of storing only the latest state. That history can rebuild past states and feed new read views. CQRS separates write commands from read queries; it can be combined with event sourcing, but neither pattern requires the other.

Conceptual flow of ordered domain events entering an event store and updating a read-only query model

Preserve the sequence of domain changes

A conventional CRUD model might store an order’s current state as “in transit.” An event-sourced model records meaningful changes such as “order placed,” “payment authorized,” and “parcel dispatched,” then derives the current state by applying them in sequence. Because an event represents something that happened, an audit-friendly correction is usually another compensating or correcting event rather than silently overwriting the old record.

An event is more than a log line or debugging trace. State changes must be initiated through the event objects, and each event needs a stable identity, ordering, and business meaning if the system is to replay it. Deciding which data belongs in an event, whether personal information must persist, and how errors are corrected are lifecycle questions to settle before choosing the store.

Replay reconstructs state, but can repeat side effects

Applying the event stream from an initial state can rebuild current state or answer a temporal query about an earlier point. The same history can also generate a new projection for a different query or screen. Replaying a very large stream can be slow, so Fowler describes keeping a snapshot of derived state and applying only later events to reduce recovery work.

Replay is safe only when state calculation is separated from external actions. If handling an old event sends a payment request or email again, rebuilding a view could trigger duplicate real-world effects. External calls need their own recording, idempotency, and deduplication rules; storing events does not solve those problems by itself.

CQRS separates reads and writes; it does not require event sourcing

Command Query Responsibility Segregation treats operations that change state as commands and operations that retrieve information as queries. The two models can share one database and still use CQRS. Separating the models can help when read and write workloads or data shapes differ enough to justify the extra design.

If the read and write stores are also split, events or another synchronization mechanism must update the read projection. Readers may then briefly see stale data, and the system must handle duplicate messages, retries, and the boundary between a database transaction and a broker publish. Microsoft describes approaches such as a transactional outbox and idempotent consumers, but these are implementation choices, not guarantees supplied automatically by CQRS. CQRS can work without event sourcing, and event sourcing can be used with a single read model.

Expert perspective: decide whether history pays for its operating cost

An event store may be useful when audit history, reconstruction at a past point, or repeated rebuilding of read models is a real product requirement. If the domain is simple and only the current value matters, ordinary CRUD can be smaller and easier to operate. A decision should include event-schema evolution, correcting bad events, replay duration, backup recovery, data retention, and deletion obligations.

Martin Fowler’s Event Sourcing page is dated December 12, 2005, and explicitly describes itself as an unfinished draft that has not been updated. It is useful for the core idea of replay and snapshots, not as current framework operations guidance. Microsoft’s CQRS article explains the command/query split and the consistency and complexity costs of separate read stores. The practical question is not whether a team can store events, but whether the business needs the history enough to own its consequences.

Sources