Event sourcing vs CQRS

Code side-by-side

Recording a bank account withdrawal and answering "what's the balance?":

// Write: append an event, nothing is overwritten
eventStore.append("account-42", {
  type: "MoneyWithdrawn",
  amount: 50,
  at: "2026-07-05T10:00:00Z",
});

// Read: replay ALL events to derive balance
function getBalance(accountId) {
  const events = eventStore.read(accountId);
  return events.reduce((balance, e) => {
    if (e.type === "MoneyDeposited") return balance + e.amount;
    if (e.type === "MoneyWithdrawn") return balance - e.amount;
    return balance;
  }, 0);
}
// Fine for one account; slow across millions

// Command side: handles the write, emits an event
function withdraw(accountId, amount) {
  validateSufficientFunds(accountId, amount);
  eventBus.publish({
    type: "MoneyWithdrawn", accountId, amount,
  });
}

// Projection: keeps the read model up to date
onEvent("MoneyWithdrawn", (e) => {
  readDb.query(
    "UPDATE account_balances SET balance = balance - $1 WHERE id = $2",
    [e.amount, e.accountId]
  );
});

// Query side: fast, direct read — no replay
function getBalance(accountId) {
  return readDb.query(
    "SELECT balance FROM account_balances WHERE id = $1",
    [accountId]
  );
}

When to use event sourcing

• You need a complete, tamper-evident audit trail. Financial ledgers, compliance-heavy domains, and insurance claims benefit from an immutable record of every change and why it happened.
• Debugging "how did we get here" incidents matters. Replaying the exact event sequence that led to a bad state is far easier than reconstructing it from row diffs or logs.
• You expect to add new views of the same history later. New analytics or reporting requirements can be answered by writing a new projection and replaying existing events — no data migration required.
• The domain is naturally event-shaped. Order processing, workflow engines, and inventory systems often map cleanly onto "things that happened" rather than "current row values."

When to use CQRS

• Read and write workloads have very different shapes or scale. A product catalogue with millions of reads per write benefits from a denormalised, cache-friendly read model decoupled from the write model.
• You need multiple, differently-shaped views of the same data. A search index, a reporting dashboard, and a mobile API can each get their own optimised read model fed from the same write side.
• Write-side business logic is complex and read-side needs are simple. Keep validation and invariants in the command handler; let the read model be a flat, denormalised projection with none of that complexity.
• You can tolerate eventual consistency on reads. If a user seeing their own change appear a few hundred milliseconds late is acceptable, CQRS's async projection lag is a non-issue.

English phrases engineers use

Quick decision tree

• Need a permanent audit trail / regulatory history → Event sourcing
• Read and write loads have wildly different shapes or scale → CQRS
• Both needs apply (audit trail + fast, varied reads) → Event sourcing + CQRS together
• Simple CRUD app, one query shape, low traffic → Neither — plain database, plain model
• Need multiple different read views of the same data → CQRS with several projections
• Team is new to the pattern and timeline is tight → Start without CQRS; add it when a real read bottleneck appears