Event_Sourcing.md

Event Sourcing (ES)

• Motivation
• Solution
  • Concepts
  • Implementation
  • Add-ons
• Pros & Cons
  • Pros
  • Cons
• Consideration
• When To Use
• References

Motivation

• Only store the current state of an entity is not enough.
• CRUD is not an ideal fit for distributed systems.

Solution

Concepts

• Persists an entity as a sequence of events.
• Each event represents a state change of the entity that has happened.
• The current state of an entity will be reconstructed by replaying the events.
• Events are persisted in an event store, which is a database or table of events.

Implementation

• A simple template of of the table storing events

  Column	Description
  Event ID	The identifier of the event.
  Event Type	The type of the event.
  Entity Type	The type of the the entity.
  Entity ID	The identifer of the entity.
  Event Data	The serialized data, such as JSON.

Add-ons

• Snapshot
  • Problem
    • An entity may have a large number of events and it is inefficient to load those events.
  • Concepts
    • Periodically persist a snapshot of the entity’s state.
    • The current state of an entity will be reconstructed by loading the most recent snapshot and only the fewer events that have occurred since the snapshot was created.
• Optimistic locking
  • Problem
    • Two or more requests to simultaneously update the same entity.
  • Concepts
    • Uses a version column to detect whether an aggregate has changed since it was read.
    • The version will be incremented by 1 whenever the entity is updated.
    • Each update statement will only succeed if the version is unchanged from when the application read the entity.

Pros & Cons

Pros

• Stateless - Decouple from the dependency on the state representation.
• Reliably publishes domain events.
• Preserves the history of entities.
  • Easy to debug an issue.
  • Some regulations (HIPPA, GLBA, SOX) or industries need audit log/trail.
• Avoids the object‑relational impedance mismatch problem.

Cons

• It has a learning curve.
• It increases the complexity of an application.
• It is not mainstream.
• Deleting data is tricky.
• Evolving events can be tricky.
• Querying the event store is challenging.

Consideration

Topic	Consideration	Possible Solution Options
Data storage	It takes a large amount of space to store every event.
Performance	It takes a long time to replay all the events for reconstructing the current state of an entity.	Consider to use snapshots to improve performance. Consider to use cache (in-memory key-value store) to improve performance.
Query data	Query multiple entities in one time.	Consider to use CQRS with Elasticsearch.
Concurrency	Multiple requests to simultaneously update the same entity.	Consider to add a version column to events (Optimistic locking). Consider to add a timestamp column to events.

When To Use

References

• Book: Chris R.(2018). Chapter 6 Developing business logic with event sourcing, Microservices Patterns (pp. 183-219). Manning Publications
• Web Article: Pattern: Event sourcing | https://microservices.io/patterns/data/event-sourcing.html
• Web Article: Event Sourcing pattern | https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
• Web Video: Event Sourcing for Enterprise, 2019 (updated) | https://www.youtube.com/watch?v=xQ5YkMBPe0o
• Web Video: From CRUD to Event Sourcing Why CRUD is the wrong approach for microservices | https://www.youtube.com/watch?v=holjbuSbv3k