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?

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)