What is Event Sourcing

Event Sourcing is a Persistence Pattern

• Basic unit of data-access is an Entity
  • Entities are stored as Streams of Events
  • 1 Stream : 1 Entity
• Current state of an entity can be restored by replaying all its events.
  • and this is the basic read-access pattern. load events, replay to calculate current state up to a point.
  • Restoring the state of the short-living entity by replaying all its events doesn't have any performance impact. Thus, no optimizations for restoring state are required for short-living entities.
    • For endlessly stored entities (like users or bank accounts) with thousands of events restoring state by replaying all events is not optimal and snapshotting should be considered.
• Event sourcing is best suited for short-living entities with relatively small total number of event (like orders).
• Read-side projections can be created as needed (later) from events. It allows responding to future needs and new requirements.

Event Sourcing is not Event Streaming

kafka = streaming

• kafka is not a DATABASE. it’s a streaming queue/pub-sub
• basic unit of time-ordering is a partition
  • kafka scales by partitioning/consumer-group-based load-balancing.
• no opinion on how many entities or even types of entities go into a given partition
  • one ENTITY per partition is uncommon and has lots of overhead
• not meant for random read-access, meant for continuous streaming
  • reading from the beginning of a topic is heavyweight. create a consumer, attach to a partition, balance it, read from zero.
• not meant for permanent storage.
  • CAN do, but increasingly expensive and from-zero replays of entire topics get slower and slower and don’t scale

event sourcing = persistence pattern

• main diff with an RDB, is things are stored as STREAM of events (or changelog), not aggregated state
• READ patterns more like traditional database
  • need to be able to READ a stream for an ENTITY from the beginning at any time.
  • an Entity’s Stream is an abstraction over the data store to force stream grouping/indexing/identification.
• WRITE patterns more like streaming
• you CAN and should be able to subscribe to all events by entity TYPE as well as entity ID.
• EventStoreDB scales using traditional database-scaling, eg. clustering/replication.

streaming and sourcing go together