Would storing a rich object as an actor with persistance be a good idea?

Question

If you are familiar with Trello, would storing an entire Trello board as an actor (with akka persistence) be a good use case?

A trello board consists of:

• lists
• tasks in a list
• each task can have comments and other properties

What are the general best practices or considerations when deciding if akka persistance is a good use case for a given problem set?

Answer 1

It mostly depends on how much write the app wants to perform.

Akka persistence is an approach to achieve very high write throughput while ensuring the persistence of the data, i.e., if the actor dies and data in memory is lost, it is fine because the write logs are persisted to disk.

If the persistence of the data is necessary, while very high write throughput is not required (imagine the app updates the Trello board 1 time per second), then it is totally fine to simply writing the data to external storage.

Answer 2

Any context where event sourcing is a good fit is a good fit for Akka Persistence.

Event sourcing, in turn, is generally applicable (note that nearly any DB you're using is event sourcing (with exceptionally frequent snapshotting, truncation of the event log, and purging of old snapshots)).

Event sourcing works really well when you want to explicitly model how entities in your domain change over time: you're effectively defining an algebra of changes. The richer (i.e. the further from just create/update) this model of change is, the more it's a fit for event sourcing. This modeling of change in turn facilitates letting other components of a system only update their state when needed.

Akka Persistence, especially when used with cluster sharding, lets you handle commands/requests without having to read from a DB on every command/request (basically, you'll read from the DB when bringing back an already persisted actor, but subsequent commands/requests (until such time as the actor passivates or dies) don't require such reads). The model of parent and child actors in Akka also tends to lead to a natural encoding of many-to-one relationships.

In the example of a trello board, I would probably have

• each board be a persistent actor, which is parent to
• lists, which are persistent actors and are each parents to
• list items, which are also persistent actors

Depending on how much was under a list item, they might in turn have child persistent actors (for comments, etc.).

It's probably worth reading up on domain-driven design. While DDD doesn't require the actor model (nor vice versa), and neither of them requires event sourcing (nor vice versa), I and many others have found that they reinforce each other.

Answer 3

would storing an entire Trello board as an actor (with akka persistence) be a good use case

I would say the size of the actor should match the size of an Aggregate Root. Making an entire board an Aggregate Root seems like a very bad choice. It means that all actions on that board are now serialized and none can happen concurrently. Why should changing description of card #1 conflicts with moving car #2 to a different category? Why should creating a new board category conflict with assigning card #3 to someone?

I mean, you could make an entire system a single actor and you wouldn't ever have to care about race conditions, but you'd also kill your scalability...