Event Sourcing Cqrs Architecture Pattern

Event sourcing and CQRS (Command Query Responsibility Segregation) are frequently confused as a single pattern in interviews, but they’re independent architectural decisions that are often paired together. Getting the distinction right — and knowing when each is worth its added complexity — is one of the clearer signals of senior-level system design maturity in 2026 interview loops, particularly at fintech, e-commerce, and audit-heavy domains (healthcare, compliance systems) where these patterns see the highest real-world adoption.

Event Sourcing: Storing State as a Sequence of Events

Traditional systems store current state directly (a users table with a balance column that gets overwritten on every update). Event sourcing instead stores the full sequence of events that led to the current state (AccountOpened, Deposited($100), Withdrew($30)) and derives current state by replaying those events. The event log is append-only and immutable — nothing is ever updated or deleted, only appended.

class Account:
    def __init__(self):
        self.balance = 0
        self.events = []

    def apply(self, event):
        if event["type"] == "AccountOpened":
            self.balance = 0
        elif event["type"] == "Deposited":
            self.balance += event["amount"]
        elif event["type"] == "Withdrew":
            self.balance -= event["amount"]
        self.events.append(event)

    @classmethod
    def from_history(cls, events):
        account = cls()
        for e in events:
            account.apply(e)
        return account

The core benefit: a complete, immutable audit trail for free, and the ability to reconstruct state as of any point in time — invaluable for financial systems, compliance-driven domains, and debugging production incidents where you need to know exactly what happened and when.

CQRS: Separating Reads from Writes

CQRS splits the model used to write data (commands) from the model used to read data (queries), often backed by entirely different data stores optimized for each access pattern. The write side optimizes for consistency and validation (e.g., a normalized relational store enforcing business rules); the read side optimizes for query performance (e.g., a denormalized document store or search index tailored to specific UI views).

CQRS does not require event sourcing — you can apply CQRS to a traditional CRUD system by simply maintaining separate read replicas with different schemas. But the two patterns pair naturally: event sourcing produces a stream of events that can drive multiple read-model projections in parallel, each optimized for a different query shape.

Comparison: When Each Pattern Earns Its Complexity

The Tradeoffs Interviewers Push On

The most common interview follow-up after a candidate proposes event sourcing: “how do you handle a schema change to an event type two years after it was first emitted?” The honest answer involves event versioning (upcasting old event schemas to the current shape at replay time) and/or snapshotting (periodically persisting computed state so you don’t replay the entire history from event zero for long-lived aggregates). Candidates who don’t proactively raise snapshot strategy for long event streams typically get pressed on it — replaying millions of events on every read is an obvious scaling problem.

The second common push: CQRS’s read model is eventually consistent with the write model, since projections update asynchronously after commands are processed. Strong candidates explicitly address how the UI handles this — e.g., optimistic UI updates on the client immediately after a successful write, while the authoritative read-model catches up in the background, with a mechanism like a returned “expected version” to detect and reconcile staleness if the user immediately re-queries.

Real-World 2026 Adoption Signal

Event sourcing/CQRS adoption remains concentrated in domains with genuine audit or temporal-query requirements — payment processors, healthcare record systems, and e-commerce order management. It has notably not become a default architecture for typical CRUD web apps, and interviewers increasingly flag candidates who reach for event sourcing as a default “impressive-sounding” answer without a specific requirement (audit trail, temporal replay, high read/write asymmetry) driving the choice. The 2026 signal of seniority is knowing when not to use it as much as knowing how it works.

For deeper coverage of when to bring up event sourcing and CQRS in a system design interview — paired with database sharding, caching, and messaging pattern tradeoffs — see The 0-to-1 SWE Interview Playbook: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20.

FAQ

Q: Do I need to implement event sourcing from scratch, or use a framework? A: In interviews, sketching the core append/replay mechanism (as shown above) demonstrates understanding. In production, teams typically use frameworks like EventStoreDB, Kafka-as-event-log, or Axon rather than hand-rolling event storage and replay logic.

Q: What’s a snapshot and why does it matter? A: A snapshot is a periodically persisted materialized view of an aggregate’s state at a given event version, so reads can start from the snapshot and replay only subsequent events rather than the full history — critical for aggregates with long-lived, high-volume event streams.

Q: How does event sourcing interact with GDPR “right to be forgotten” requirements? A: This is a genuine tension since the event log is meant to be immutable. Common real-world solutions include crypto-shredding (encrypting PII fields with a per-user key that gets deleted, rendering historical events unreadable for that user) rather than literally deleting or mutating historical events.