In the [Payment System](/learn/system-design/questions/payment) question, you need to know exactly how an account reached its current balance. In [Google Calendar](/learn/system-design/questions/google-calendar), you want to undo a meeting change and see what the schedule looked like yesterday. In [Ads Click Aggregator](/learn/system-design/questions/adds-click-aggregator), every single click matters for billing, and losing one is losing money. Traditional CRUD databases cannot answer these questions well. When you UPDATE balance = 500, the previous value is gone. There is no record of _how_ it became 500, no way to rewind, no audit trail. For systems where history, correctness, and replayability matter, you need a fundamentally different approach. That is what **event sourcing** and **CQRS** provide. They are separate ideas that pair naturally together, and they show up in many showoffer questions. ## Why Events Instead of State? In a traditional CRUD system, your database stores the _current state_. An UPDATE overwrites whatever was there before. This works fine for many applications, but it has a fundamental limitation: it destroys information. **Event sourcing** flips this model. Instead of storing current state, you store the _sequence of events_ that produced it. The current state is derived by replaying all events from the beginning. For a bank account, instead of storing balance: 500, you store: - AccountOpened (initial: 0) - MoneyDeposited (amount: 1000) - MoneyWithdrawn (amount: 300) - MoneyWithdrawn (amount: 200) The current balance (500) is computed by replaying these events in order. Every event is **immutable** -- you never update or delete an event. To "undo" something, you append a **compensating event** (for example, RefundIssued). **See it in practice:** The [Payment System](/learn/system-design/questions/payment) question is the canonical event sourcing application -- every financial transaction is recorded as an immutable event in an append-only ledger. The [Leaderboard](/learn/system-design/questions/leaderboard) question benefits from event sourcing because score changes can be replayed to rebuild rankings after rule changes. ## The Event Store The core of event sourcing is an **append-only event log**. Each entry records what happened, when it happened, and to which entity. Events are never modified or deleted. Every event carries a few key properties: - **Event type**: what happened (OrderCreated, ItemAdded, OrderPaid) - **Aggregate ID**: which entity it belongs to (order #42) - **Timestamp**: when it happened - **Payload**: the data associated with the event To get the current state of an entity, you load all its events and replay them in order. This gives you three superpowers that CRUD cannot match: **Complete audit trail.** Every change is recorded with who, what, and when. This is a legal requirement for financial systems and invaluable for debugging production issues. **Temporal queries.** Need to know the state at 3pm yesterday? Replay events up to that timestamp. Need to know when a specific change happened? Search the event log. **Event replay.** Ship new business logic? Replay old events through it. Need to backfill a new analytics dashboard? Replay the entire event history. Need to debug a production issue? Replay the exact sequence of events that led to the bug. **See it in practice:** In [Bookstore](/learn/system-design/questions/bookstore), event sourcing provides an audit trail for inventory changes -- every stock adjustment, purchase, and return is traceable. In [Online Chess](/learn/system-design/questions/online-chess), the full move history is an event log that enables replay, analysis, and dispute resolution. ## Snapshots -- Making Replay Fast There is an obvious problem with replaying events: as the event log grows, reconstruction gets slow. Replaying a million events to compute a single account balance is impractical. The solution is **snapshots**. Periodically, you save a snapshot of the current state at a known event position. To rebuild state, load the latest snapshot and replay only the events that came after it. Snapshots are purely an optimization. They can always be regenerated from the event log. If a snapshot is corrupted or outdated, you simply rebuild it by replaying from the beginning (or from an earlier snapshot). A common strategy is to take a snapshot every N events (for example, every 1000 events) or on a time schedule. The right frequency depends on your read patterns -- if an entity is read frequently, snapshot more often. **See it in practice:** In [ChatGPT](/learn/system-design/questions/chatgpt), conversation history is essentially an event log of messages. Snapshotting the conversation context periodically avoids reprocessing the entire history on every new message. In [File System](/learn/system-design/questions/file-system), file version history can be stored as a sequence of diffs (events) with periodic full snapshots for fast access. ## CQRS -- Separate Reads From Writes **Command Query Responsibility Segregation** (CQRS) separates the **write model** (commands like "create order" or "update inventory") from the **read model** (queries like "get order details" or "list recent orders"). Each model uses a data store and schema optimized for its access pattern. The write model stores data normalized for consistency and validation. The read model stores data denormalized for fast queries -- pre-joined, pre-aggregated, indexed by the exact access patterns the UI needs. An event bus (Kafka, EventBridge) propagates changes from the write side to the read side asynchronously. CQRS does not require event sourcing, and event sourcing does not require CQRS. But they complement each other naturally: events from the event store feed directly into CQRS read model projections. **See it in practice:** In [Yelp](/learn/system-design/questions/yelp), the write model handles review submissions with validation while the read model serves pre-computed restaurant pages with denormalized ratings. In [Slack](/learn/system-design/questions/slack), messages are written to a consistent store but read from denormalized channel views optimized for the chat UI. The [Scaling Reads](/learn/system-design/design-patterns/scaling-reads) pattern covers the read-side optimizations (replicas, caching, CDN) that CQRS read models leverage. ## Event Projections -- Many Views From One Source One of the most powerful aspects of event sourcing combined with CQRS is **projections**. A projection is a function that processes events and builds a specific read model. You can run multiple projections over the same event stream, each producing a different view optimized for a different use case. For example, from the same stream of order events, you might build: - An **order details view** for the customer-facing dashboard (optimized for lookup by order ID) - An **analytics aggregation** for the business team (optimized for time-range queries and trend analysis) - A **search index** in Elasticsearch (optimized for full-text search across orders) Each projection processes events independently. Adding a new projection does not change the write path or affect existing projections. If a projection falls behind or has a bug, you can rebuild it by replaying events from the beginning -- the event store is the single source of truth. ## The Two-Phase Event Pattern In systems like [Payment System](/learn/system-design/questions/payment), losing track of an operation mid-flight is catastrophic. The **two-phase event pattern** ensures no intent is lost: 1. **Before processing**: Write a `PaymentInitiated` event to the event store. This records the intent -- even if the system crashes during processing, recovery knows a payment was attempted. 2. **Process**: Call the payment gateway, execute the transaction. 3. **After processing**: Write either `PaymentCompleted` or `PaymentFailed` with the result details. If the system crashes between steps 1 and 2, a recovery process finds `PaymentInitiated` events without a corresponding completion event and retries or alerts. No payment intent is ever silently lost. This pattern extends beyond payments to any operation where losing the intent is worse than duplicate processing: order placement, inventory reservation, fund transfers. It pairs naturally with [Pub/Sub Messaging](/learn/system-design/design-patterns/pub-sub-messaging) for downstream notification of completed events. **See it in practice:** The [Payment System](/learn/system-design/questions/payment) question uses two-phase events to guarantee no transaction is silently lost during processing. The [Webhook](/learn/system-design/questions/webhook) question uses a similar intent-first pattern -- record the delivery intent before attempting it, so failures can be retried. In [Job Scheduler](/learn/system-design/questions/job-scheduler), job state transitions (scheduled, running, completed, failed) form a natural event log that enables recovery after scheduler crashes. ## Trade-offs and Pitfalls Event sourcing and CQRS add real complexity. Before reaching for them, make sure you actually need the benefits. **Eventual consistency.** CQRS read models are updated asynchronously. After a write, the read model may take milliseconds to seconds to reflect the change. For most use cases (dashboards, search) this is fine. For read-your-own-writes scenarios, route the user's reads to the write model briefly after they write -- the same technique used with [read replicas](/learn/system-design/design-patterns/scaling-reads). **Schema evolution.** Events are immutable, but your event schema will evolve over time. Version your events and write upcasters that transform old event formats to new ones during replay. This is manageable but requires discipline. **Storage growth.** The event store only grows. For high-throughput systems, this means significant storage over time. Compaction strategies (archiving old events, keeping only snapshots for ancient history) help manage this, but the event store will always be larger than an equivalent CRUD database. **Complexity.** Two data models, event handlers, projection logic, snapshot management, eventual consistency handling -- this is significantly more moving parts than a simple CRUD application. If you don't need audit trails, temporal queries, or independent read scaling, a well-designed CRUD system with the [Scaling Reads](/learn/system-design/design-patterns/scaling-reads) and [Scaling Writes](/learn/system-design/design-patterns/scaling-writes) patterns may be all you need. **See it in practice:** In [Distributed Counters](/learn/system-design/questions/distributed-counters), the eventual consistency trade-off of CQRS is directly visible -- counter reads may lag behind writes. In [Meta Post Privacy](/learn/system-design/questions/facebook-post-privacy), CQRS principles help separate the privacy-rule write model from the feed-rendering read model, each scaled independently. The [Stream Processing and Real-Time Aggregation](/learn/system-design/design-patterns/stream-processing-realtime-aggregation) pattern extends event sourcing ideas into real-time analytics pipelines.