# Event sourcing vs CQRS > Event sourcing stores authoritative state as a sequence of events; CQRS separates the models used to change state from those used to query it. Use event sourcing when durable business history and state reconstruction justify the complexity, CQRS when reads and writes need different models, and both when you need both benefits. Source: https://sysround.com/compare/event-sourcing-vs-cqrs Updated: 2026-11-05 ## Side by side | | Event sourcing | CQRS | |---|---|---| | Main concern | How authoritative state is stored | How commands and queries are modeled | | Source of truth | Persisted domain events | Not prescribed; often current-state tables | | Write path | Validate command, append resulting events | Execute commands through a write model | | Read path | Reconstructed state or derived projections | Query-specific read models | | Separate databases | Not required | Not required | | Historical reconstruction | Supported if required events and logic remain available | Requires a separate history mechanism | | Consistency | Atomic appends possible; async projections may lag | Synchronous or asynchronous read-model updates | | Main operating cost | Event evolution, replay, retention, snapshots | Multiple models, synchronization, stale reads | ## The differences that matter They answer different questions, so they are not competing architectures. Event sourcing asks whether persisted events are the authoritative record from which state is derived. CQRS asks whether commands and queries should use different models. You can use either alone or combine them. With event sourcing, a command such as ReserveFunds produces a fact such as FundsReserved. The event is committed before the operation is acknowledged, and current state can be reconstructed from the stream. With CQRS alone, the same command can update ordinary relational tables while queries use a separate summary model. Keeping an audit table beside mutable state does not automatically make the system event-sourced. CQRS does not require microservices, a message broker, or separate databases. Command and query models can share one database and update transactionally. If read models are maintained asynchronously, clients may see stale results. Event-sourced projections have the same issue when updated asynchronously, but neither pattern inherently requires every read to be eventually consistent. Event sourcing adds a long-lived compatibility obligation: old events must remain interpretable as application code evolves. Snapshots reduce reconstruction work but do not replace the authoritative history. CQRS adds the responsibility of maintaining useful read models and, when synchronization is asynchronous, monitoring lag and recovering failed updates. Neither pattern removes the need for concurrency control, idempotency, or cross-service coordination. ## Choose Event sourcing when - You need to reconstruct business state at earlier points in time, and retaining current state plus a conventional audit log would not meet that requirement. - The domain benefits from explicit historical facts, such as funds reserved, orders accepted, and reservations canceled. - You need to build new projections from retained business history, and that history contains the information those projections require. - You can support event schema evolution, replay tooling, retention policies, and privacy requirements throughout the system's lifetime. ## Choose CQRS when - Reads need denormalized summaries, search documents, or other models that differ substantially from the transactional write model. - Read and write workloads need independent optimization or scaling, without making an event history the source of truth. - Current-state storage already meets correctness and audit requirements, but one shared model makes commands or queries unnecessarily complicated. - You want separate command and query models within one service or database before taking on asynchronous synchronization. ## Worked example: Reservation history versus fast availability queries Suppose a ticketing service manages 50,000 seats for an event and receives 20,000 availability queries per second during a sale. CQRS can keep seat holds in transactional tables while serving a section-level availability projection. That projection may lag, so the hold command must check authoritative inventory rather than trust the displayed count. Event sourcing is a separate choice: persist SeatHeld, HoldExpired, and SeatSold as authoritative events only if reconstructing reservation history is worth the operational cost. Combining both allows those events to feed availability projections. For competing holds, an atomic expected-version append or another transactional guard must reject the loser; neither a fast projection nor the event log alone prevents overselling. ## In the interview - Start by saying the patterns are orthogonal. Identify the authoritative data first, then explain how commands are validated and how queries are served. - Tie event sourcing to a concrete history or reconstruction requirement. Expect follow-up questions about event versions, snapshots, deletion requirements, and replay without repeating external side effects. - Tie CQRS to specific query shapes or workload differences. Explain whether models share a database, how updates reach the read side, and what happens when that path fails. - State the freshness contract. If a user must see a successful write immediately, discuss returning the committed result, reading the authoritative write state, or waiting for a projection to reach a returned version. - Explain concurrency separately from projection freshness. Expected stream versions can reject conflicting event appends, but invariants spanning multiple streams or services still need explicit coordination. ## Common mistakes - Presenting event sourcing and CQRS as mutually exclusive choices, or assuming that adopting one requires the other. - Calling any append-only message stream event sourcing without identifying whether it is the authoritative, sufficiently retained record of business state. - Assuming CQRS requires two databases and eventual consistency, then adding infrastructure without a workload-driven reason. - Treating replay as harmless re-execution. Projection rebuilds must not resend payments, emails, or other external side effects, and retryable consumers need duplicate handling. ## Interview questions where it comes up - [Design a payment system](https://sysround.com/questions/design-payment-system): Compare authoritative financial history with current balance projections while keeping concurrency, idempotency, and reconciliation explicit. - [Design a stock trading app like Robinhood](https://sysround.com/questions/design-robinhood): Separate authoritative order and ledger transitions from query views without treating a lagging projection as sufficient for cash or share reservations. - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Distinguish fast availability read models from authoritative seat allocation, then evaluate whether reservation history warrants event sourcing. - [Design Facebook post search](https://sysround.com/questions/design-facebook-post-search): Explain a CQRS-style search read model fed from authoritative post state without requiring event sourcing or trusting stale index permissions. ## FAQ ### What is the difference between event sourcing and CQRS? Event sourcing determines how authoritative state is persisted: as a sequence of events. CQRS separates command models from query models. They address different concerns and can be used independently or together. ### Can you use CQRS without event sourcing? Yes. Commands can update current-state tables while queries use separate models or projections. Those models can share a database, or separate stores can be synchronized through mechanisms such as change data capture or an outbox. ### Does event sourcing require CQRS? No. An application can reconstruct an entity from its events and serve queries directly from that state without introducing separate query models. CQRS often becomes useful when replaying entity streams does not efficiently answer search, aggregation, or cross-entity queries. ## Related concepts - [Event sourcing](https://sysround.com/concepts/event-sourcing) - [CQRS](https://sysround.com/concepts/cqrs) - [Materialized views](https://sysround.com/concepts/materialized-views) - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) - [Schema evolution](https://sysround.com/concepts/schema-evolution) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.