Skip to content
Learni
View all tutorials
Architecture Logicielle

How to Implement Event Sourcing in 2026

18 minADVANCED
Domain-Driven DesignArchitectureEvent SourcingCQRS
Lire en français

Introduction

Event Sourcing is a foundational architectural paradigm in 2026 for highly resilient distributed systems. Instead of storing an entity's current state (like in traditional CRUD models), you persist the immutable sequence of events that led to it. Picture a bank account: rather than recording a final balance of €1500, you store 'Deposit of €1000', 'Withdrawal of €200', 'Interest of €700'. This provides infinite traceability, horizontal scalability through projections, and state reconstruction at any time.

Why adopt Event Sourcing today? In a world of microservices and generative AI, regulatory audits (GDPR, finance) demand a full change history. It pairs perfectly with CQRS (Command Query Responsibility Segregation) to separate writes and reads, boosting OLTP performance up to 10x. This advanced, code-free tutorial guides you from theory to advanced pitfalls, with real cases like banking or e-commerce systems. By the end, you'll model complex aggregates and scale in production. (148 words)

Prerequisites

  • Strong grasp of Domain-Driven Design (DDD): aggregates, entities, value objects.
  • Knowledge of CQRS and Event-Driven Architecture.
  • Experience with databases: SQL/NoSQL, ideally event stores like Kafka or Axon.
  • Understanding of concurrency patterns: optimistic locking, versioning.
  • Familiarity with immutability and idempotence principles.

Event Sourcing Fundamentals

Event Sourcing rests on three pillars: immutability, atomicity, and replay.

  • Immutability: Events are append-only, never modified. Analogy: a ship's log where each entry is carved in stone.
  • Atomicity: Each event captures a single atomic state change, validated by business rules.
  • Replay: To get the current state, sequentially 'replay' all events on an aggregate.
Real-world example: Bank account. Events: AccountCreated(€1000), DepositMade(€500), WithdrawalMade(€200). State at t=3: balance=€1300 via 1000 +500 -200. Benefit: precise temporal audits, impossible with a simple UPDATE balance=1300.

CRUD vs. Event Sourcing: CRUD mutates state (UPDATE users SET balance=1300), losing history. Event Sourcing scales via event stream sharding.

Modeling Events and Aggregates

An event is an immutable past fact: Event { type: string, data: object, timestamp: Date, aggregateId: UUID, version: int }.

Modeling rules:

  • Fine granularity: One event = one unique business decision.
  • Bounded Context: Events scoped to DDD domains.
  • Versioning: Increment to detect conflicts.

Case study: E-commerce. Order aggregate:
EventDataState Effect
---------------------------
OrderPlaced{products: [...], total: €250}Status='PendingPayment'
PaymentConfirmed{amount:€250, ref:'PAY123'}Status='Paid', stock-=quantities
ShipmentSent{tracking:'TRK456'}Status='Shipped'

Pitfall: Avoid overly broad events like OrderModified; prefer ProductAdded, ProductRemoved for better traceability.

Event Store and Persistence Management

The Event Store is an append-only database partitioned by stream (one per aggregate instance). Typical structure: events table with columns aggregate_id, sequence, event_type, payload (JSON).

Advanced queries:

  • Stream read: SELECT * FROM events WHERE aggregate_id=? ORDER BY sequence.
  • Temporal position: Timestamp index for CDC (Change Data Capture).

Scalability: Horizontal sharding by aggregate_id. For 1M events/day, Kafka shines as an Event Store with compaction.

Bank example: Stream account-uuid-123: 1000 events/year. Reconstruction: foldLeft(InitialState, events.map(applyEvent)). Performance: O(n) but n stays small via snapshots (see below).

Integrating CQRS and Projections

Event Sourcing pairs with CQRS: Commands mutate the Event Store (write side), Queries read materialized views (read side).

Projections: Asynchronous processes transforming events into optimized views.

  • Synchronous: For low latency (in-memory projection).
  • Asynchronous: Via Kafka Streams or Apache Flink for scale.

Projection framework:
  1. Subscribe to events topic.
  2. Apply event to view: on(PaymentConfirmed) { updateStockView() }.
  3. Persist view in read-optimized DB (Elasticsearch).

E-commerce case: StockView projection: incremented by OrderPlaced, decremented by Cancellation. Result: O(1) queries vs. O(n) replays.

Advanced Management: Snapshots, Concurrency, and Temporal Queries

For n>10k events, use snapshots: Periodic stored states (every 1000 events). Reconstruction: snapshot + delta events.

Concurrency:

  • Optimistic: Check version before append; reject on conflict.
  • Pessimistic: Distributed locks (via Redis), rare in Event Sourcing.

Temporal Queries: "State at date X?" → Replay up to timestamp X.

Example: Bank, simultaneous deposit/withdrawal → reject second with VersionConflictError, client retries.

Best Practices

  • Enriched events: Include userId, correlationId for traceability.
  • Idempotence: Unique commandId on commands; skip if already applied.
  • Smart snapshots: Adaptive frequency (log(n) events) + LZ4 compression.
  • Multiple projections: One per use case (audit, analytics, UI).
  • Monitoring: Track projection lag, stream sizes; alert >1h.
  • Migration: Event upcasting for schema evolution without downtime.

Common Mistakes to Avoid

  • Anemic events: Incomplete data → can't reconstruct. Solution: Always full context.
  • Costly replays: No snapshots → timeouts. Cap at 5000 events/stream.
  • Tight projection coupling: One failure blocks others. Use dead-letter queues.
  • Ignoring versioning: Lost concurrency → corruption. Always increment and validate.

Next Steps

  • Books: "Implementing Domain-Driven Design" by Vaughn Vernon; "Event Storming" by Alberti.
  • Tools: Axon Framework, EventStoreDB, Kafka + Debezium.
  • Case studies: Uber (Schemaless Event Store), Netflix (analytics).
  • Learni Training: Event-Driven Architecture for hands-on DDD+CQRS.
  • Conferences: QCon, DDD Europe 2026.