A brief overview of the technologies involved and how we've used them at Fifty3North to deliver a real-time event based products using EventStore, Orleans and Redis

2. ▪ Solution developed for Capture Education
▪ Software for nurseries to collect evidence of
learning
▪ Existing web based version built by another
supplier

3. ▪ Offline support
▪ iOS and Android
▪ Phone and tablet
▪ Companion parent app
▪ Scales to minimum 100k concurrent users

4. •
•

5. Command and Query
Responsibility Segregation.
Separating the reads from
the writes makes sense
because most applications
are either read heavy or
write heavy. By separating
these you can scale them
independently.
Consists of many actors made
up of their own behaviour and
optionally own private state.
Communication with actors
and between actors is message
based. By default, an actor can
process a single message at a
time and any further messages
passed to an actor will be
placed in a mailbox for future
processing. Traditionally uses
many nodes in a cluster to host
actors to scale computation.
Storing events which
triggered state changes
within the system as a
stream of facts. These facts
can be used to rehydrate
state at any time.
Greg Young’s Event Store
https://geteventstore.org is
one implementation (we
use this)

6. ▪ Virtual Actors - distributed computing with a low barrier to entry.
▪ All calls must be async using standard async await and use the standard Orleans Task Scheduler.
▪ Avoid .Wait() and .Result at all costs.
▪ All method parameters must be serializable.
▪ No need to worry about whether the actor (grain) is located
on a local or remote node (silo).
▪ Update multiple data stores concurrently
▪ Writes are instant, read models are eventually consistent.
▪ Tell (Perform an action, change state etc.)
▪ Ask (Give me information)
▪ See http://bit.do/orleankka

7. ▪ A command handler in the actor decides if the
Command can be processed.
▪ If this validation is successful, an Event is raised.
▪ This event is the source of truth for the entire
system.
▪ It is an undisputed action that happened at a point
in time. This is the most important piece of
information. All other information can be derived
from these events.
▪ Because of this, the first thing we do is write it to
the event store.
▪ We then use the event to mutate the actor’s state.
This is an in-memory update to state so is very fast.

11. ▪ Read the list of events from EventStore for this actor
▪ Call event handler on the actor for each event in the stream
▪ Very fast – in memory updates only
▪ Snapshots enabled every 100 events

12. ▪ Forwards on events to other actors
▪ Used to create transaction as a result of a command
▪ Implicit subscriptions to actors’ Orleans streams
▪ Re-entrant & Worker attributes

15. Post
Post
Post
Post
Post
Post
Post
Post

16. Changeset Key
44ba5b1b Post-18
e30a5db7 Post-19
218d88c8 Post-20
afa982a8 Post-21
3c5db22a Post-22
71ef2652 Post-23
Partition 1
(Organisation X)
44ba5b1b
afa982a8
Key Data
Post-18 {JSON}
Post-19 {JSON}
Post-20 {JSON}
Post-21 {JSON}
Post-22 {JSON}
Post-23 {JSON}
Partition 2
(Organisation Y)
e30a5db7
71ef2652