Voxxed Bristol 2017 - From C to Q, one event at a time: Event Sourcing illustrated By Lorenzo Nicora

Voxxed Days Bristol 2017 Lorenzo Nicora - @nicusX

From C to Q, one Event at a time

1

Lorenzo Nicora OpenCredo

Event Sourcing illustrated


Lorenzo Nicora @nicusX

[email protected] https://opencredo.com/author/lorenzo/

Senior Consultant @ OpenCredo • Microservices • Cloud • Event-driven, Event Sourcing, Reactive • Java, Spring, Akka…

2

3

Concepts from DDD


Aggregate

Event Sourcing,CQRS => DDD/

State: f(t)

Domain Event

Voxxed Days Bristol 2017 Lorenzo Nicora - @nicusX 4

Once upon a time…

Everything was Synchronous

Request <-> Response


Scaling out…

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

-> Distributed still Synchronous


Let’s go Asynchronous

-> Distributed & Message-drivenRequest/Response ACID Transactions

• Distributed: Propagation takes time • Async: No global order strictly guaranteed

Updates applied in the wrong order => Inconsistent state!


Command Sourcing💡

• Append Only —> No Contention, No Update • Build State from Commands history

K/V Store Distributed

Command “Submit this Order! (Please)” ->A request (imperative sentence) ->May fail, be rejected ->May affect multiple Aggregates

8

Commands


✉

Rebuild Aggregate State from Commands

9

Events


Event “Order submitted” -> Statement of facts (past tense) ->Never fails ->Can’t be changed ->May be designed to affect a single Aggregate

✉

Rebuild Aggregate State from Events


Command > Event Sourcing💡


Commands to Events

X

Y

Z?


(Business) Consistency

(ACID) Transactions

Eventual (Business) Consistency

Guess —> Compensate —> Apologies


e.g. Saga

StatefulOut of band

Corrective Action(Command / Event)

Saga


–Greg Young

“Accountants don’t use pencils.

They use pens”

Corrective Actions

14


Benefits of Event Sourcing

History (for free)

Rebuild State at a point in Time



Easier Eventual Business Consistency

—> Corrective Events

Robust to data corruption (bugs, malicious, fat fingers…)



Horizontal Scalability &

Low Latency writes

-> Distributed systems & data store

—> Append-only Log

—> Asynchronous processing


Commands to Events

Stateful: Events depends 0n current State

Stateless: Validate, split by Aggregate…

Depends on Business Domain

x Point of synchronisation? Out-of-order commands (IoT, Mobile)


Thinking fast or slow

Stateless: Think fast,

Write fast, More thinking later

Stateful: Think slow…(rebuild state),

Write fast, Less thinking later


What about reads?

20


Retrieving the State

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

❔

not very efficient, but… …may work


Querying (Searching) the State❓How do query the State?

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


CQRS

Command Query Responsibility Segregation

💡

Separate • Code • muService • Datastore

-> Update -—> Retrieve


Not a new idea

Specialised

Downstream


CQRS and Event Sourcing

for low-latenc

y writes

Event Sourcing => CQRS


Materialised Views

• In MemoryK/V Store Graph DB RDBMS

• Rebuildable from Events

💡a.k.a. Read-optimised Views Read Views Projections…


Materialised Views

* Views are optimised for specific query use cases

—> multiple Views from same Events

* May be updated asynchronously + low latency writes, scalability - delayed + may reorder Events


Materialised Views

The Event Log is your Source of Truth

* Easy to evolve or fix —> change or fix logic; rebuild view from events


Indexes

• Search EnginesK/V Stores Graph DB

+ Optimised for querying (less for retrieving) + Reduced delay of State

💡


Hybrid solutions: e.g. Snapshots

+ Speed up rebuilding the State

+ Use recent Events to rebuild up-to-date

💡Long delayed

Distributed + Asynchronous system Distributed ACID Transactions (2PC)

31

No Global Current State


AS

SA

B

Information propagates at a finite speed


Lessonfrom the Trenches


Lesson Learned #1

If you put data in…

…you will eventuallyhave to get them out!

The “Query” side is not secondary


Lessons Learned #2

In old days:normalising one DB

to support as many queries as possible

With CQRS (also No SQL in general)

multiple denormalised “data stores” optimised for different queries


Lessons Learned #3

Centralised Event Store= Event-sourced monolith

Each microservice owns its state (Event Store)

Microservices:


+++ Summing up +++

36


ES/CQRS Optimal Use Cases

• High Volume, Low Latency writes

• Out-of-order Commands (IoT, Mobile)

Event Sourcing + CQRS😋

Domain: stateless Command-> Event


ES/CQRS Drawbacks

x No “One-Size-Fits-All”

—> Multiple “Q” implementations

x Delayed reads

x No ACID Transactions

x Additional complexity (!!!)

🙁


ES/CQRS Benefits

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

+ Distributed systems (Microservices)

+ Eventual (Business) Consistency

+ History, Temporal queries

+ Robust to data corruption

😀


That’s all, Folks!

40


??? Questions ???

41

Thanks.

⏳

Technology

Voxxed Bristol 2017 - From C to Q, one event at a time: Event Sourcing illustrated By Lorenzo Nicora