Actors should be inherently persistent unless no longer reachable.

What i mean by persistent is : what is the best practice to save an actor’s state so that it can be properly restored in case of a crash without loosing information.

I think i’m still not clear on how you would design a transactional system ( such as order & paiement processing ) with actors in a way that won’t make it look like a microservice based system ( aka : one per subtask, fetching info from a db for each incoming request, and storing the result in a db in the end)

It seemed to me actors had to have a more fine grained context ( such as one per order), but in that case i’m wondering how it’s supposed to handle saving its state regularely so that no information on the order processing state is ever lost

Excellent question! But your question seems to make the unfounded assumption that application programmers should be in charge of restoring crashed Actors. Instead, an Actor System should restore Actors as best it can based on recordings that it has. Applications must be made resilient against any and all kinds of inconsistencies that will pervasively arise.

Do you know any resource i could read that would explain how all that is supposed to work out in practice ?

I've never heard of an actor system able to automatically respawn actors with their previous state (the whole system would look like a tree of cached data, each layer responsible for saving the leafs under it, with a huge "persist to DB" on top , wouldn't it ?). Does erlang OTP do those kind of things ?

Edit: also, are you Prof "Carl" Hewitt ? The one that invented actors ? I'd be honored you found a question of mine about actors excellent...

This is what I am building. I'm building a database of actors that are free agents in a way.

The key insight is that an actor is a tiny VM and you just need to make the VM state durable.

I see many challenges :

- not all states transitions need to be durable. If performance matters you’ll have to get your actors to call something like a « saveState » from time to time, otherwise every single property change is going to have an overhead in terms of performance.

- what does « durable » mean ? Surely, just having the state of an actor saved in the memory of the supervisor isn’t enough. If the two are on the same server and the server shuts down, it’s game over. You need a « persistence » service / actor, but that thing is going to have to persist the state of all the actors in your system. I don’t see how that can work if you’ve got millions of actors running in parallel.

Durability is a matter of degree. Lowest is to record in RAM. Next is persistent local storage. After that comes storage on other machines.

That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.

You should check how Erlang / Elixir database drivers handle that.

In my experience with Elixir there are never many processes that have a state to save in a database. Eventually it's the same load no matter if the implementation is actor based or object oriented.

but then how do you deal with transactionnal behaviors ?

Check Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html

The general idea is to build the transaction in a pipeline of function calls. Each function gets the old definition of the transaction as an argument and returns a new one. Eventually the call at the end of the pipeline executes the statements in the definition, wrapping them in a transaction.

If the question is how to deal with 100 or 100 k concurrent transactions, the answer again is in the same way a cluster of servers running programs written in any other language do. Eventually SQL is SQL.

I'm building my own database-like thing