How to build resilient distributed systems using Akka.NET Persistence module.

1. Event Sourcing and beyond
with Akka.NET Persistence
Konrad Dusza
Head of Engineering @ Bilander Group

2. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Agenda
● Recap of the actor model and Akka.NET
● Persistence module - capabilities and use cases
● Akka.NET Persistence sample
● Additional Akka.NET Persistence features

3. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Actors communicate by exchanging messages
asynchronously
Actors have internal state that is invisible from the
outside, no shared mutable state
Actors can decide to change their state upon
reception of a message - behavior specification
Each actor processes immutable messages
sequentially - one message at a time*
Actor model - “concurrent object-oriented programming”
Actor
State
Behavior
Messages

4. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Actor model - “concurrent object-oriented programming”
Actors can create child actors
Actors are identified by addresses
Actors have mailboxes, where messages arrive
By default, messages are processed in the order
in which they arrived
/Anakin
Come to
the dark
side!
/Anakin/Luke /Anakin/Leia

5. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Actor model - benefits
No deadlocks!
No shared state!
No global mutable state!
Fault isolation - “let it crash”!
Encapsulation!

6. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Actor frameworks - features
● “Green” threads
● Supervision tree
● Remote deployment
● Routing
● Clustering
● Distributed Pub-sub
● Conflict-free Replicated Data Types (CRDTs)
● Hot code reloading

7. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Akka.NET Persistence
When actor dies, its state is lost
Supervision tree will restart it, with a clean slate (state)
To recover the state, durable storage must be used.
Couldn’t we just store the actor state in durable storage and retrieve during restart?
Enter - Akka.Persistence

8. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Akka.Persistence - core features
State persistence for stateful actors
Record events based on messages for eventual recovery - Event Sourcing
Optionally persist state snapshots
At-least-once delivery using AtLeastOnceDelivery mixin for PersistentActor
Pluggable storage (MS, PostgreSQL, MySQL, Cassandra, SQLite, etc. )

9. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Hello persistent actor
What’s needed?
ActorSystem in our application
Actor inheriting from UntypedPersistentActor or ReceivePersistentActor
(or analogous AtLeastOnce* versions)
Define PersistenceId for the Actor
Register Command handlers that generate Events which change the state
(Commands come from the outside)
Register Recovery handlers (for Event replay, in case of failure)
Deploy actors using actor system (or indirectly via router)
Configured event journal data store

10. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Persistent actor with snapshots
What’s needed?
Configured snapshot store
Implement logic for triggering snapshot storage and retrieval

11. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Actor
1.Command
(not persisted)
2. Event
(persisted)
3. State update
4. State Snapshot
(optional, persisted)
Persistent actor - command processing flow

12. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Actor
1. Recovery triggered
2. Load snapshot state
(optional)
3. Process remaining persisted events
(with state updates)
Persistent actor - recovery flow

13. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Hello AtLeastOnceDelivery actor
Why?
By default, Akka message delivery is the weakest - at-most-once guarantee
Often in distributed systems, we need a stronger guarantee - at-least-once,
which can be used to guarantee exactly-once delivery
What’s needed?
Actor must inherit from AtLeastOnceDelivery.*Actor
Actor must send using new Deliver methods and handle Confirm messages
Duplicate messages handling

14. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
AtLeastOnceDeliveryActor
1. Deliver ( message )
AtLeastOnceDelivery message exchange
Actor
Keep on resending until
confirmed
2. Confirm delivery
Store
unconfirmed
delivery
Delivery
confirmed, time
to chill out :)
During recovery, messages with confirmed delivery are not
sent again. Unconfirmed messages are sent after recovery.

15. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Example - cash machine and bank processes
Scenario
User accesses his bank account via a CashMachine,
Allowed operations: withdraw, deposit money, check account balance
Actors
CashMachine (AtLeastOnceDeliveryActor, SQLite backend)
Banker (PersistentActor, MS SQL backend)
AkkaNetPersistenceSamples.sln

16. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Example - DebitAccount process
AkkaNetPersistenceSamples.sln
CashMachine
(Actor)
DebitAccount (amount)
Banker
(Actor)
Keep on resending until confirmed!
Confirm delivery
CashMachine
(GUI)
Guaranteed<DebitAccount> (amount)
Persist event
(MessageQueued<DebitAccount>)
Persist event (AccountDebited),
Update account state
Optionally - save state snapshot
User
clicks
“debit”

17. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Additional features (1)
● Clean up old messages and snapshots (!)
○ Messages can be deleted using DeleteMessages method (ToSeqNumber)
○ Snapshots can be deleted using DeleteSnapshot(s) methods
● Event adapters
○ Built-in support for event schema migrations (aka upcasting)
○ Translations between data model and domain model for events
○ Specialized event persistence on a per event type basis

18. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
● Persistent Finite State Machines
○ Persistence for Akka’s FSM
○ More explicit modeling of states and transitions between them, with event sourcing and snapshotting
● Persistent Query (new) / View (deprecated)
○ Query side of CQRS pattern
○ ReadJournal for materializing read side queries using Akka Streams
■ Subscribe to events, in a read-optimized manner
■ Materialize values of queries
■ Allow for querying events by tags, provided by event adapters
○ Akka.Persistence.Query - separate Nuget, still in beta.
○ Akka.Persistence.Query.Sql - ReadJournal implementation for ADO.NET stores.
Additional features (2)

19. Voltcode Actor model in .NET - Akka.NetVoltcode Event sourcing and beyond with Akka.NET PersistenceVoltcode
Additional features (3)
● Cluster Sharding (with Akka.Cluster)
Library for implementing entities (objects with id) sharding with support for:
● automatic distribution - split entities across cluster nodes without manually providing their
target addresses
● rebalancing of entities (objects with id) - handle cluster membership changes (nodes coming in
and going)
Special actor “coordinator” takes care of shardig management. It requires an event journal accessible
by all of the participating nodes.
CRDTs (Akka.DistributedData) can be used to achieve the same functionality, but it is now in experimental
stage

20. Event sourcing and beyond with Akka.NET PersistenceVoltcode
Resources
Code samples (soon) available under:
https://github.com/voltcode/AkkaNetPersistenceSamples
Find out more about Akka.NET and the Actor Model:
http://getakka.net
https://github.com/akkadotnet/akka.net/
https://gitter.im/akkadotnet/akka.net
https://petabridge.com/bootcamp/
http://petabridge.com/blog
http://bartoszsypytkowski.com/
Many resources available for Akka (Lightbend documentation)
actor model, clusters in general (Erlang, Riak - basho)
Book(Scala) : Reactive Design Patterns