From C to Q, one event at the time: Event sourcing illustrated [Voxxed Ticino 2017]

Voxxed Days Ticino 2017 Lorenzo Nicora - @nicusX
From C to Q 
one Event at a time
1
Lorenzo Nicora
OpenCredo
Event Sourcing illustrated

Lorenzo Nicora
@nicusX
lorenzo.nicora@opencredo.com
https://opencredo.com/author/lorenzo/
Senior Consultant
@ OpenCredo, London
• Microservices
• Cloud
• Event-driven, Event Sourcing, Reactive
• Java, Spring, Akka…
2

3
Concepts from DDD
Aggregate
Event Sourcing,CQRS => DDD/
State: f(t)

Voxxed Days Ticino 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-driven
Request/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
—> scale horizontally

Command
“Submit this Order!”
-> 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
Eventual (Business) Consistency
Guess —> Compensate—> Apologies
Long (Business) Transactions

e.g. Saga
Stateful
Out of band
Corrective Action 
(Command / Event)
Saga

–Greg Young
(and Pat Helland before him, https://goo.gl/dCKDgw )
“Accountants don’t use pencils.
They use pens”
Corrective Actions
14

Beneﬁts 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 commands
-> Distributed systems & data store
—> Append-only Log
—> Asynchronous processing

18
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
Event Sourcing => CQRS

Materialised Views
• In Memory 
K/V Store 
Graph DB 
RDBMS 
• Rebuildable 
from Events
💡
a.k.a.
Read-optimised Views
Read Views
Projections…
“Weak” persistence

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

Forward compatibility
The Event Log
is your Source of Truth
* Easy to evolve or fix
—> change or fix logic;
rebuild view from events

Indexes
• Search Engines 
K/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

Multiple Read Models
* Read Models are optimised for  
specific query use case
Event stream —> multiple Read Models

Lesson 
from the Trenches

Lesson Learned #1
If you put data in…
…you will eventually 
have 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 read models 
optimised for different queries

Lessons Learned #3
Don’t use  
Event Sourcing
if your behaviour  
is CRUD

+++ Summing up +++
36

ES/CQRS Drawbacks
x No “One-Q-Fits-All”
—> Multiple “Q” implementations
x Delayed reads
x No ACID Transactions
x Additional complexity (!!!)
🙁

ES/CQRS Beneﬁts
+ C and Q scale independently
+ Distributed systems (Microservices)
+ Eventual (Business) Consistency
+ History, Temporal queries
+ Robust to data corruption
😀

Happy use case
Stateless Command processing
(Commands —> Events)
+ High Volume (Big Data)
+ Low-latency commands
+ Out-of-order Commands 
(IoT, Mobile)
😀

That’s all, Folks!
40

??? Questions ???
41
Thanks.
⏳

From C to Q, one event at the time: Event sourcing illustrated [Voxxed Ticino 2017]

Recommended

Recommended

More Related Content

Similar to From C to Q, one event at the time: Event sourcing illustrated [Voxxed Ticino 2017]

Similar to From C to Q, one event at the time: Event sourcing illustrated [Voxxed Ticino 2017] (20)

Recently uploaded

Recently uploaded (20)

From C to Q, one event at the time: Event sourcing illustrated [Voxxed Ticino 2017]