Event sourcing in HLD - System Design Guide

Problem Statement

When a system stores only the current state, it loses the history of changes. This makes it hard to audit, debug, or reconstruct past states. If data corruption or bugs occur, recovering previous states or understanding how the system reached its current state becomes nearly impossible.

Solution

Event sourcing solves this by storing every change as a sequence of events. Instead of saving just the final state, the system records all actions that led to it. The current state is rebuilt by replaying these events in order, preserving full history and enabling easy recovery and auditing.

Architecture

Client App

→Command Handler

↓

↓

Aggregate State

→Event Handler

This diagram shows how client commands are handled to produce events stored in an event store. The aggregate state is rebuilt by replaying events from the event stream.

Trade-offs

✓ Pros

→

Preserves complete history of all changes for auditing and debugging.

→

Enables easy recovery of past states by replaying events.

→

Supports temporal queries and time travel debugging.

→

Facilitates integration with other systems via event streams.

✗ Cons

→

Increases storage requirements due to storing all events.

→

Rebuilding state can be slow if event streams grow large without snapshots.

→

Adds complexity in handling event versioning and schema evolution.

Use when auditability, traceability, or complex state reconstruction is critical, especially in systems with complex business logic or regulatory requirements. Suitable for systems with moderate to high write volumes where event history is valuable.

Avoid when system state changes are simple and history is not needed, or when write throughput is extremely high and event storage overhead is prohibitive.

Real World Examples

LinkedIn

Uses event sourcing to track user activity and profile changes, enabling detailed audit trails and rollback capabilities.

Uber

Applies event sourcing to model ride lifecycle events, allowing reconstruction of ride states and handling complex workflows.

Amazon

Employs event sourcing in order management to maintain a full history of order state changes for auditing and customer service.

Alternatives

State-based persistence

Stores only the current state snapshot without recording individual changes.

Use when: When system simplicity and low storage overhead are priorities and historical data is not required.

Command Query Responsibility Segregation (CQRS)

Separates read and write models; can be combined with event sourcing but focuses on query optimization.

Use when: When read and write workloads differ significantly and need separate optimization.

Summary

Event sourcing records every change as an event, preserving full history.

It enables rebuilding system state by replaying events in order.

This pattern improves auditability and debugging but adds storage and complexity overhead.