What a use case for Akka persistent actor?

Question

I'm in mess about the applicability of Akka Persistence, and the persistent actors, when I should use a persistent Actor?

Taking for example from a Cart module of a given Shopping Application, will be every user's Cart Session a persistent actor with respective unique persistenceId?

What's the usability in real applications? How the query side handles the state of the persistent actor? When the persistent actor is not useful in real applications?

Storing states or store messages, are the same thing? Aren't? What's the difference, when I should use each one?

Can someone give me some examples?

Group

I believe persistent actors is the Write side in CQRS and you still need to handle the Read side in some sort of queryable storage. Actors in Akka are by definition event-sourced, so I see no fundamental difference with any event sourced system for handling queries (of course I realize the rest of the differences). – Iloilo

Answer 1

This is going to be highly opinionated question, and highly opinionated answer.

Imagine that you have a task management system, e.g. Jira or alike. Let's say you have a following layout of actors:

• Project 1
  • Ticket 1
  • Ticket 2
• Project 3
  • Ticket 3

If projects and tickets are actually persistent actors, then you have, compared to the standard approach (query etc), the following benefits:

• Putting actor up and down restores its state - so no more complex queries and mapping to the actor code. Moreover, if your app is down, restarting it essentially loads the data with all the history (below)
• Actor model/Akka supervision gives you additional bonus - if your actor has died (i.e. task died when trying to obtain data from external integration), restarting it will bring it back with all the history.
• Tracking history is already in there (and you can model your data so that events journal actually includes all the change data like user and timestamp, as well as old value/new value). This actually is applicable to bazillions of business domains - for instance, trade processing, where each trade has to store its own history.
• Another part is query - if your system allows eventually consistent design, you can just scatter the data to all of the tickets in the project with however complex query you want and wait for responses.

The usefulness comes from design of your application - some are well-suited (i.e. multiple separate or loosely coupled entities), some are not so well (i.e. you want to just store the single last set of data and generate a predefined report of it)

Necaise

About the relationship between Ticket concept and Actor. By this example we'll have an actor "ticket1", another actor "ticket2" and so on? – Group

Correct - IMO, the best candidate for becoming PersistentActors are the stateful entities in domain - ticket/project/trade/whatever you like – Necaise

Now I'm beginning to understand this, so an actor based application, like Akka, could be composed by millions of actors? Thank you for the answers! – Group

It's even better. Akka app can have millions of actors in run time - as long as you have the memory. In Akka Persistence case, you can have literally infinite amount of actors, bringing them up and down - with state stored in the event journal – Necaise