Slide deck used for the meetup talk at Glassbeam - intro into event sourcing, CQRS, Akka persistence leading up to DDD

1. 11
CQRS + ES with Scala and Akka
Bharadwaj
19th June 2016

2. Agenda
1. Event Sourcing  CQRS  Akka and Distribution  DDD
2. Demo

3. Bank Database
Question 1: Is the balance in your bank account a value from a column
on a row in a relational database?

4. Bank Database
Question 1: Is the balance in your bank account a value from a column
on a row in a relational database?
Question 2: How many of you would be comfortable if it were a value
from a column/row?

5. Bank Database
Question 1: Is the balance in your bank account a value from a column
on a row in a relational database?
Question 2: How many of you would be comfortable if it were a value
from a column/row?
“Bank balance is an equation”

6. 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

7. • 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

8. Event Sourcing
Journal of Immutable Facts aka Events in an append
only fashion

9. Event Sourcing
Journal of Immutable Facts aka Events in an append
only fashion
Event sourcing is actually just functional code

10. … thats NOT a practical database
• it will have too much data…

11. … 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

12. … 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…

13. … 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)

14. … 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)
• how do you even model an application with this thing...

15. … 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)
• how do you even model an application with this thing...
– CQRS 

16. 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

18. 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

19. Akka Persistent Actor Plugins
• Journal
– Cassandra, Kafka, Hbase, JDBC
• Snapshots
– Cassandra, Kafka, Hbase, JDBC

20. Command and Event Distinction
• Commands generate Events
• Events are immutable facts that can be replayed to restore
application state

21. Persistent Actor

22. Snapshotting Persistent Actor

23. 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

24. Demo

25. Akka persistence magic
1. No direct function calls or message passing between read and write side
!

26. 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 !!

27. 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 !!!

28. 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 !!!
4. Mix this with Akka clustering and a distributed journal to scale
horizontally !!!!

29. 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

30. 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

31. 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…

32. 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