CQRS + ES with Scala and Akka

11

CQRS + ES with Scala and Akka

Bharadwaj19th June 2016

Agenda

1. Event Sourcing CQRS Akka and Distribution DDD

2. Demo

Bank Database

Question 1: Is the balance in your bank account a value from a column

on a row in a relational database?

Bank Database



Question 2: How many of you would be comfortable if it were a value

from a column/row?

Bank Database



Question 2: How many of you would be comfortable if it were a value

from a column/row?

“Bank balance is an equation”

Shopping Cart for a Event

• T1: Tickets go on sale at: ₹100

• T2: 10 Tickets sold

• T3: Ticket price increased to: ₹200

• T4: 2 tickets purchased between T1 and T2 get cancelled

• Every update or delete from a database results in

loss of data

• Databases with constant updates and deletes are

actually ‘shared mutable state’ of an application.

And ‘shared mutable state’ is evil

Event Sourcing

Journal of Immutable Facts aka Events in an append

only fashion

Event Sourcing

Journal of Immutable Facts aka Events in an append

only fashion

Event sourcing is actually just functional code

… thats NOT a practical database

• it will have too much data…



– storage will only getting cheaper

– tradeoff: data loss vs. volumes

– not for every problem: when data is important






• every read will be a full table scan…







– periodic rollup or snapshot

– snapshot: in functional programming, that is, current state = foldLeft (previous

states)









states)

• how do you even model an application with this thing...









states)

• how do you even model an application with this thing...

– CQRS

CQRS

• Command Query Responsibility Segregation

• CQRS says read and write paths need to be handled separately by applications

• Segregation because reads and writes almost always have very different

properties in every system

– Difference in order of magnitude of each in a system

– Difference in SLA

• Build them separately so that both can be scale. Using a singular layer like ORM

for both cannot be scaled

How to keep the write-side journal and read-side data-

store best effort consistent?

Akka allows the events created via commands to be sent

across to the read side to keep read models consistent

and update them quickly

Akka Persistent Actor Plugins

• Journal

– Cassandra, Kafka, Hbase, JDBC

• Snapshots

– Cassandra, Kafka, Hbase, JDBC

Command and Event Distinction

• Commands generate Events

• Events are immutable facts that can be replayed to restore

application state

Persistent Actor

Snapshotting Persistent Actor

Persistence Query

• Persistent Query actors send responses to incoming query messages

• Polls the Journal

• Each persistence query tracks either of:

– a single persistence-id

– a ‘tag’ shared by events of different persistent-ids

• Different options to build ‘materialization’ (snapshot) in persistent queries depending on

how one may want to materialize and the capabilities exposed by underlying Journal store

• Different types of persistence query actors would be needed in an application based on the

domain and queries

Akka persistence magic

1. No direct function calls or message passing between read and write side

!



!

2. Restart the application to see the automatic state recovery !!



!


3. Underneath, Akka plumbs the read and write side when they are on the

same JVM to reduce round-trip and faster read side updates !!!



!


3. Underneath, Akka plumbs the read and write side when they are on the

same JVM to reduce round-trip and faster read side updates !!!

4. Mix this with Akka clustering and a distributed journal to scale

horizontally !!!!

Akka Addendum

• Akka Persistence View is deprecated and Persistence Query takes its place

• Akka Persistence Actors (Write side) have to be cluster singletons

• Just using Akka Clustering with Akka Persistence severely limits the possibilities since cluster singletons in clustering are always placed on the oldest node. To control actor placement within the cluster, use Akka Sharding

• Different CQRS implementations with Akka:– ‘Eventsourced’ was the first CQRS project on Akka. It supported up to Akka 2.2.0. Akka

persistence is influenced by it and was released in Akka 2.4.0. ‘Eventsourced’ is now legacy

– ‘Eventuate’ is an alternative to Akka persistence. It seems to have more features than Akka persistence

– Experimental

How to design a system or app with ES and CQRS… ?

• How to model Persistent Actors? How to model Persistent Query’s?

• Designing commands and events and aggregates

How to design a system or app with ES and CQRS… ?

• How to model Persistent Actors? How to model Persistent Query’s?

• Designing commands and events and aggregates

• DDD domain driven design

– Eventual consistency

– No distributed transactions

– Many more…

References

• Akka Persistence Documentation

• Greg Young: CQRS and Event Sourcing -

https://www.youtube.com/watch?v=JHGkaShoyNs

• Sander Mak: Event Sourced Architectures with Akka -

https://www.youtube.com/watch?v=vFVry457XLk

• Martin Krasser: Event Sourcing and CQRS with Akka Persistence and Eventuate

- https://www.youtube.com/watch?v=vFVry457XLk

https://www.youtube.com/watch?v=JHGkaShoyNs



CQRS + ES with Scala and Akka

Software

Transcript of CQRS + ES with Scala and Akka