Event Sourcing

Why This Comes Up in Interviews

Event sourcing appears in designs for financial systems, audit-heavy domains, and any system needing "time travel." Interviewers want to hear:

• Why append-only is fundamentally different from update-in-place
• How you handle event replay and system recovery
• When CQRS is needed alongside event sourcing
• Concrete trade-offs: storage cost, complexity, query patterns
• How eventual consistency manifests and how you manage it

Event Sourcing vs Traditional CRUD

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
graph TB
    subgraph Traditional CRUD
        CMD1[Transfer $100] --> DB[(Database)]
        DB -->|UPDATE accounts SET balance = balance - 100| STATE1[Current State Only]
    end

    subgraph Event Sourcing
        CMD2[Transfer $100] --> STORE[(Event Store)]
        STORE --> E1[MoneyDeposited $500]
        STORE --> E2[MoneyWithdrawn $200]
        STORE --> E3[MoneyTransferred $100]
        E1 --> PROJECTION[Current State = Replay All Events]
        E2 --> PROJECTION
        E3 --> PROJECTION
    end

    style DB fill:#e74c3c,color:#fff
    style STORE fill:#27ae60,color:#fff
    style PROJECTION fill:#3498db,color:#fff

Core Components

Event Store Design

Back-of-envelope: Storage sizing

At ~\(0.02/GB/month for cold storage: **~\)1,300/year** — cheap for a complete audit trail.

Snapshots — Avoiding Full Replay

The problem: An aggregate with 100,000 events takes seconds to replay on every request.

The solution: Periodically save a snapshot of the current state.

Replay with snapshot:

1. Load latest snapshot (state at event #9500)
2. Replay only events #9501 through #9612 (112 events instead of 9612)
3. Latency: 2ms instead of 200ms

CQRS Integration

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
graph LR
    subgraph Write Side
        CMD[Command] --> HANDLER[Command Handler]
        HANDLER --> VALIDATE{Validate}
        VALIDATE -->|OK| STORE[(Event Store)]
    end

    subgraph Read Side
        STORE -->|Subscribe| PROJECTOR[Event Projector]
        PROJECTOR --> READDB[(Read DB - Optimized)]
        QUERY[Query] --> READDB
    end

    style STORE fill:#27ae60,color:#fff
    style READDB fill:#3498db,color:#fff
    style HANDLER fill:#f39c12,color:#fff

Why CQRS + Event Sourcing pair naturally: Events are great for writes (append-only, fast) but terrible for reads ("show all orders over $100 this month" requires replaying millions of events). CQRS lets you build query-optimized read models from the same event stream.

Event Versioning — Schema Evolution

Events are stored forever, but your domain evolves. How do you handle old events?

Best practice: Use upcasting for minor changes, versioned events for breaking changes. Never modify stored events.

Eventual Consistency — The Trade-off

Read-your-own-writes pattern: After a command succeeds, the response includes the new version number. Client passes this version to read queries. Read side either waits for projection to catch up or reads directly from event store.

When to Use Event Sourcing

Real-World Implementations

Interview Framework

When event sourcing is relevant in system design:

Step 1: "For this domain (e.g., banking, e-commerce orders), I'd use event sourcing because we need a complete audit trail and the ability to reconstruct state at any point in time."

Step 2: "Every state change is stored as an immutable event in an append-only log. The current state is derived by replaying events. For performance, I'd snapshot every 100 events to avoid full replay."

Step 3: "For reads, I'd use CQRS — project events into query-optimized read models. This gives us fast reads without compromising the write model's simplicity."

Step 4: "The trade-off is eventual consistency between write and read sides (~100-200ms lag) and increased storage. But we gain: complete audit, easy debugging, ability to rebuild read models, and replay for recovery."

Quick Recall