Design an Event Sourcing System

Dynamic Schema Evolution with Upcasters

As business requirements evolve, domain event schemas inevitably change through added fields, deprecated flags, or structural renames. Because historical events are immutable and cannot be rewritten in storage, the system applies read time upcasters to transform legacy representations on the fly:

// Dynamic event upcasting layer applied during read time deserialization
// schemaVersion describes payload shape, while streamVersion represents the aggregate revision
interface StoredEventV1 {
  schemaVersion: 1;
  type: "OrderCreated";
  data: { items: Array<{ productId: string; qty: number }>; total: number };
}

interface StoredEventV2 {
  schemaVersion: 2;
  type: "OrderCreated";
  data: { items: Array<{ productId: string; qty: number }>; subtotal: number; tax: number; total: number };
}

export function upcastOrderCreated(event: StoredEventV1): StoredEventV2 {
  return {
    ...event,
    schemaVersion: 2,
    data: {
      items: event.data.items,
      subtotal: event.data.total,
      tax: 0,
      total: event.data.total,
    },
  };
}

When to Avoid Event Sourcing

Event sourcing introduces notable engineering complexity through eventual consistency, projection maintenance, and schema migration overhead. Teams should avoid this pattern when designing straightforward CRUD applications without historical audit needs, when entity schemas change too unpredictably to maintain upcasters, or when strict synchronous read consistency is a firm architectural requirement.

Saga Choreography vs Orchestration

Managing distributed transactions across multiple aggregate boundaries requires choosing between choreography and orchestration.

In choreographed sagas, services listen to domain events and react autonomously. For example, an OrderCreated event triggers payment processing, which subsequently emits a payment confirmation event. This approach provides loose coupling for simple two-to-three step workflows, but becomes difficult to trace when business flows branch conditionally.

In orchestrated sagas, a dedicated saga manager coordinates the entire workflow by dispatching explicit commands and tracking intermediate state transitions in a dedicated saga event stream. Orchestration provides centralized observability and cleaner failure management when coordinating five or more steps. Regardless of the coordination model, sagas maintain immutability by appending forward-compensating events such as VoidPayment or ReleaseInventory rather than deleting historical records.

Interview Walkthrough

A structured pacing guide for navigating a 45-minute event sourcing architecture interview:

• 25-minute cut

  Focus on the write path, optimistic concurrency, and CQRS projection mechanics before introducing advanced replay features.

  • Contrast CRUD overwrites with append only events and justify when auditability and replay warrant the complexity (5 min)
  • Draw the CQRS separation: event store for writes and asynchronous projection builders for denormalized reads (6 min)
  • Explain optimistic concurrency control using expected stream revisions on every append (5 min)
  • Cover snapshot checkpoints to cap state hydration latency and establish Kafka as the durable event backbone (5 min)
  • Staff depth: schema upcasting, point in time temporal queries, and blue green projection rebuilds (4 min)
• Open by contrasting destructive CRUD overwrites with append only event streams, establishing early that event sourcing preserves complete audit lineage.
• Draw the CQRS boundary clearly, positioning the PostgreSQL event store on the command side and Kafka-driven projection builders on the query side.
• Detail optimistic concurrency control using expected stream versions to reject concurrent write conflicts without holding database row locks.
• Introduce materialized snapshots for long lived aggregates so command handlers replay only recent delta events rather than entire multi-year histories.
• Solve the database to Kafka delivery gap using either the Transactional Outbox pattern or Debezium CDC so committed events are published reliably without an application-level dual-write race.
• Explain schema evolution through read time upcasters because stored historical events are immutable and cannot be modified in place.
• Quantify write scale early: 5B events per day at 500 bytes per event generates 2.5 TB daily, requiring uniform stream partitioning across Kafka brokers.
• Highlight the critical architectural pitfall of attempting to serve user-facing queries by replaying raw event streams on every request, which leads to unacceptable query latency.

Related Problems

Event sourcing and CQRS patterns connect directly to these specialized distributed systems architectures and core infrastructure concepts:

• Event Sourcing and CQRS explores foundational command and query segregation, event stream schemas, and projection lifecycle management.
• Write-Ahead Logging (WAL) and Data Durability examines sequential append logs, fsync flush policies, and crash recovery mechanics.
• Distributed Transactions: 2PC vs Saga contrasts blocking two-phase commit protocols with asynchronous compensating saga workflows.
• CAP Theorem and Consistency Models analyzes strong vs eventual consistency boundaries between write models and asynchronous projections.
• Microservices Patterns: Strangler, Saga, and Outbox details the transactional outbox pattern and message relay strategies for reliable event publication.
• Kafka Architecture and Guarantees covers partition ordering, consumer group offset commits, and high throughput log replication.
• Distributed Message Broker explores low latency pub-sub log architectures, consumer group balancing, and partition assignment strategies.
• Payment Gateway demonstrates how immutable ledgers, idempotent transaction keys, and audit logging protect financial transactions.