Event sourcing

As explained in Akka in Action, Second Edition

Event sourcing is a persistence technique that stores state changes as an ordered sequence of events and reconstructs current state by replaying them.

Event sourcing stores state changes as an ordered, append-only sequence of events rather than repeatedly replacing one state value. A journal preserves the event order, and replaying those events reconstructs the current state so a persistent actor can continue after restart. section 1.5.1 section 9.2

A persistent actor follows this command-to-recovery flow:

• Receive a command expressing an intention to change state. section 9.2
• Validate the command by executing it against the actor’s current state. section 9.2
• Generate and append an event when the resulting state is accepted. section 9.2
• Replay the journal’s events after restart to restore the last known state. section 1.5.1 section 9.2

Recovering a conversation

A Conversation actor receives messages and records MessageAdded events in a journal. On startup, it retrieves those events in write order and replays them into its in-memory conversation, avoiding database operations in the actor’s application logic. section 1.5.1 section 1.5.1

Events are immutable facts: changing the event history would remove the approach’s advantage. When event fields evolve, preserve old entries and deserialize multiple versions, supply defaults for added fields, or use event adapters rather than rewriting the journal. section 9.3.5 section 9.3.5

Figure 9.6 Persistent actor recovery

Use the recovery diagram to trace how journaled events rebuild a persistent actor after restart. section 9.2

How Akka in Action, Second Edition covers it

How deep it goes

Explains commands, validation, event append, replay, immutability, and versioned deserialization; defers event-adapter details.

Examples

Uses Conversation actors with MessageAdded events and cargo events whose schemas gain or lose fields over time.

What it assumes

Assumes actors, messages, and in-memory state; initially postpones serialization and other persistence details.

What you can do after

Operate persistent actors by validating commands, appending events, replaying journals, and accommodating event-schema versions.

How it connects

Connects persistent actors, journals, commands, event replay, serialization, schema evolution, and sharding.

liveBookmanning.com

Read Akka in Action, Second Edition on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Kafka for ArchitectsAn event-sourced system persists state changes as an ordered sequence of events from which current state can be reconstructed.

Compare how 2 books explain event sourcing →

Related concepts

• append-only systemuses · An append-only system preserves existing data and records changes by adding new entries without modifying or removing prior entries.
• CQRSaddressed by · CQRS is an architectural pattern that separates operations and models for changing application state from those for querying or reading state.
• Akka Persistenceused by · Akka Persistence is an Akka module for building actors whose state can be durably stored and recovered from persisted events or snapshots.
• auditabilityproduces · Auditability is the ability to trace, inspect, and verify a system’s actions, decisions, changes, or records using available evidence.
• Apache Kafkauses · Apache Kafka is a distributed event-streaming platform for publishing, storing, processing, and consuming streams of records.

This explainer was generated by Manning's knowledge graph from the text of Akka in Action, Second Edition. The section links point to the parts of the book it draws on.