A Visual Introduction to Event Sourcing and CQRS by Lorenzo Nicora

A visual introduction to

Event Sourcing and CQRS

1

@nicusX https://opencredo.com/author/lorenzo/

Lorenzo Nicora Senior Consultant @ OpenCredo

2

A couple of concepts from DDD

Aggregate

(Current) State of the Aggregate

Lorenzo Nicora Intro to Event Sourcing and CQRS

3

Once upon a time…

Everything is synchronous

Request - ResponseLorenzo Nicora Intro to Event Sourcing and CQRS

4

Scaling up…

Updates —> Locks —> Contention!<— Block <—


5

Let’s go Asynchronous

Pwd —> “secret” Pwd —> “12345” Pwd —> “54321”

Pwd —> “secret” Pwd —> “54321” Pwd —> “12345”

===> Out of Order

Asynchronous, Message-drivenRequest/Response ACID Transaction

Distributed, Message-based —> No order guaranteed


6

Command Sourcing💡

• Append Only —> No Contention • Build State from Command history

Write fast, Think later

K/V Store Distributed


Command “Submit Order!” —> A request (imperative sentence) —> May fail —> May affect multiple Aggregates

7

Commands vs Events

✉

Rebuild Aggregate State from Commands


8

Event “Order submitted” —> Statement of facts (past tense) —> Never fails —> May affect a single Aggregate

✉

Rebuild Aggregate State from Events


9

Commands to Events

(DDD patterns: Aggregate / Process Manager)

X

Y

Z


10

Command > Event Sourcing💡

Think a little, Write, Think later


11

Event Sourcing

In many domains Commands ≃ Events


12

Additional Benefits

EasyEventual Business Consistency

—> Corrective Events

Robust to data corruption (bugs, fat fingers…)

—> Rebuild state ignoring wrong events


13

Additional Benefits

History (for free)

Rebuild State at a point in Time


14

Main Benefit

Scalable —> Append only

-> Fits distributed k/v stores

—> Low-latency writes

—> Allows asynchronous processing


What about reads?

15Lorenzo Nicora Intro to Event Sourcing and CQRS

16

Retrieving the State

How do I retrieve the State? “Get details of Order ‘AB123’”

❔

not very efficient, but… …may work


17

Querying (Searching) the State

❓

❓How do query the State?

“Get all Orders delivered to ‘SE1 0NZ’”

❓

❓


18

CQRS

Command Query Responsibility Segregation

💡Separate • Code • muService • Datastore

-> Update -—> Retrieve “Query”

datastore is downstream


19

Not a new idea

Specialised Downstream


20

CQRS and Event Sourcing


21

Materialised Views (of current State)


22

Materialised Views (of State)

Latest (known) State

(Persistent)Rebuildable from Events

In MemoryK/V Store Graph

… RDBMS

Delayed

💡


23

Materialised View of State

Query a RDBMS?!?

Wasn’t it the old way?

❓

RDBMS is just one of our options: easy to use, easily become a bottleneck


24

Materialised Views of State

* Views are optimised for specific query use cases

—> multiple Views from same Events

* Updated asynchronously, delayed —> to Scale -> may reorder Events


25

Materialised Views of State

* Views can be rebuilt from Events

Event Log is our Source of Truth

* Easy to evolve or fix

—> change or fix logic; rebuild view from events

(not the View)


26

Indexes


27

Indexes

Search EnginesK/V Stores

• Optimised for querying (less for retrieving) • Latest State; rebuild on the fly

💡


28

Hybrid solutions


29

Hybrid solutions: e.g. Snapshots

• Speed up rebuilding the current State • Use recent Events to rebuild up-to-date

💡Long delayed


30

Eventual (Business) Consistency

Guess —> Compensate —> Apologies


31

Eventual Consistency: Sagas

StatefulOut of band

Corrective Command or Event

Saga


32

Lessonfrom the Trenches


33

Lesson Learned #1

If you put data in…

…you will eventuallyhave to get them out!

The “Query” side is not secondary


34

Lessons Learned #2In old days:

normalising one DB to support as many queries as possible

With CQRS: multiple denormalised “data stores”

optimised for different queries

No single “Q” implementation for all your queries


35

Lessons Learned #3

A central, shared Event Storemay not be the best option

No Event-sourced Monolith

Prefer persistence per Bounded-Context


+++ Summing up +++


37

ES/CQRS Optimal Use Cases

High Volume Low Latency writes

(big data)

Event Sourcing + CQRS

😋

Out-of-order Commands/Events (IoT)


38

ES/CQRS Drawbacks

x No “One-Size-Fits-All”

—> Multiple “Q” implementations

x Delayed reads

x No ACID Transactions

x Additional complexity (!)

🙁


39

ES/CQRS Benefits

+ No “One-Size-Fits-All” —> “Q” are optimised for use cases

+ Eventual (Business) Consistency

+ History, Temporal queries

+ Robust to data corruption

😀


That’s all, Folks!


??? Questions ???

41

Thanks.

⏳


A Visual Introduction to Event Sourcing and CQRS by Lorenzo Nicora

Technology