Event Sourcing

Architectural Patterns

Meaning

Event Sourcing is an architectural pattern that persists application state as an append-only sequence of immutable domain events rather than by mutating current state in place. It addresses the pain point of losing historical context, audit trails, and the ability to reason about how state evolved over time. It is reached for when the domain demands full change history, temporal queries, or the ability to reconstruct any past state deterministically.

Primary Function

State persistence

Communicative Purpose

Enables complete reconstruction of past states and full audit history by storing every state change as an immutable event rather than overwriting current state.

Pattern

capture domain event → append to immutable event store → derive current state by replaying events (optionally from snapshot)

Função primária

State persistence

Propósito comunicativo

Enables complete reconstruction of past states and full audit history by storing every state change as an immutable event rather than overwriting current state.

Situações de gatilho

Domain modeling: when business events (orders placed, funds transferred) are the natural unit of change and must be auditable Compliance/finance: when regulators require immutable history of every state transition Distributed systems: when services must rebuild local state by replaying events from an event log

Contextos

Domain-Driven Design, CQRS architectures, microservices, financial systems, supply-chain platforms, audit-heavy enterprise domains

Padrão

capture domain event → append to immutable event store → derive current state by replaying events (optionally from snapshot)

Colocados típicos

event store
event log
aggregate
command
projection
snapshot
replay
upcaster
domain event
CQRS

Substituições comuns

CRUD persistence (simpler but loses history and audit trail)
state-machine persistence (tracks current state only
no replay)
log-structured storage (similar low-level mechanism but lacks domain semantics)
event-driven architecture (uses events for messaging
not as the source of truth)

Erros comuns

Storing events with denormalized payloads and no version field → breaks replay when the event schema evolves Treating events as transient messages that can be edited or deleted → destroys the audit guarantee and corrupts derived state Skipping snapshots for long-lived aggregates → state reconstruction becomes unusably slow after thousands of events Applying event sourcing to simple CRUD domains → adds significant complexity (projections, versioning, replay) for no benefit Writing non-idempotent event handlers → duplicate processing on retry corrupts derived projections

Similar / contraste

CRUD: mutates current state directly with no history Event-driven architecture: uses events for inter-service communication but does not persist them as the source of truth Audit logging: records changes for inspection but does not drive application state CQRS: separates read and write models, often paired with event sourcing but conceptually independent

Interferências

Coming from CRUD thinking: may try to update or delete past events to 'fix' mistakes — events are immutable facts; corrections are new compensating events Coming from message-queue systems: may treat events as transient messages to be consumed and discarded — in event sourcing the event log IS the database Coming from OOP stateful objects: may mutate fields directly on the aggregate — state changes must be expressed as appended events, not in-place assignment

Família do chunk

CQRS
event store
aggregate
projection
snapshot
domain event
upcaster
saga

Nuance

When NOT to use: simple CRUD apps, domains with no audit or temporal-query requirement, or systems where eventual consistency is unacceptable Performance: replay cost grows linearly with event count; mitigate with periodic snapshots and projections built from snapshots plus subsequent events Boundary conditions: events must be backward-compatible or versioned via upcasting; projections can be rebuilt but only if the original event stream is preserved; aggregate boundaries must be carefully drawn so events for one aggregate never reference another's internal state

Efeito pragmático

Enables temporal queries (state at any point in time), full regulatory audit trails, debugging by replaying events, and the freedom to build new read models without losing historical data — at the cost of higher infrastructure complexity and the discipline of immutable event design.

Dica de memória

Event Sourcing is like a bank's transaction ledger: every deposit and withdrawal is recorded as an immutable fact, and your balance is always derived by replaying the ledger — never by overwriting a stored number.

Upgrade path

Event sourcing combined with CQRS, snapshotting strategies, and projection rebuild pipelines

Frequência: MediumFormulaicidade: FlexiblePrioridade de aquisição: Active recallPrioridade de output: BothTag de espaçamento: Long-term

Examples

class BankAccount: def __init__(self, account_id): self.account_id = account_id self.events = [] self.balance = 0 def deposit(self, amount): self.events.append({"type": "Deposited", "amount": amount, "at": now()}) self.balance += amount def withdraw(self, amount): if self.balance < amount: raise InsufficientFunds() self.events.append({"type": "Withdrawn", "amount": amount, "at": now()}) self.balance -= amount @classmethod def from_events(cls, account_id, events): account = cls(account_id) for event in events: if event["type"] == "Deposited": account.balance += event["amount"] elif event["type"] == "Withdrawn": account.balance -= event["amount"] return account

class Order: def __init__(self, order_id): self.order_id = order_id self.pending = [] self.status = "pending" def place(self, items): self.pending.append(OrderPlaced(order_id=self.order_id, items=items)) self.status = "placed" def ship(self, tracking_id): if self.status != "placed": raise InvalidStateTransition() self.pending.append(OrderShipped(order_id=self.order_id, tracking_id=tracking_id)) self.status = "shipped" def commit(self, event_store): for event in self.pending: event_store.append(stream=f"order-{self.order_id}", event=event) self.pending.clear()

def rebuild_order(order_id, event_store): order = Order(order_id) events = event_store.read(stream=f"order-{order_id}") for event in events: if isinstance(event, OrderPlaced): order.status = "placed" order.items = event.items elif isinstance(event, OrderShipped): order.status = "shipped" order.tracking_id = event.tracking_id elif isinstance(event, OrderCancelled): order.status = "cancelled" return order