mungobungo

Ahh great. “On Erlang, State and Crashes” is exactly answering my question.

As for disks - in good old times when servers were pets, not cattle that was a good idea. But now when the servers are as ephemeral as actors, we need to approach it differently, hence my original question.

Sidenote - i have a strange relationship with Erlang. I first learned it in 2006, liked the idea and was hoping it will eat the world as scale increases. I even contacted Joe Armstrong in hope to translate his thesis. Zero Erlang books in the world at the time. Then i did some load tests using Tsung in 2012. Then i used akka.net in 2018. But till this day i never had a chance to properly use in production.

Thank you, i was not aware of the Horde package. Definitely worth looking.

I was also thinking what should happen in case of ‘electricity disappears’ scenario, but came to a conclusion that it is good old ‘save the state you care about’

What i had in mind is some kind of gen_fsm or gen_statemachine.

For stateless applications it is pretty obvious how supervision trees can improve the reliability. Essentially the only ‘state’ there is request itself. Worst case scenario client would just retry.

But with some state involved it becomes not as simple.

Essentially the answer to my question probably would be like : “you should store the state in the external system, and design your system in such a way that stored state is always consistent. In case of failure supervisor will respawn the process and it will recreate what it needs from the saved state”

Well, let’s assume we are talking about a webshop. Every user is represented as an actor, a cart might be a state. So cart as a state should be stored somewhere else, let’s say redis. And every single read/write operation would be a network hop. What are the benefits of using actor model then ?

As for state handover between pods - what are the keywords to look for ?

Practical question here. How are Elixir/Erlang apps being deployed nowadays?

My understanding is that BEAM is designed for long running setups where hot reload of the code makes sense, and reboots are not happening that often thanks to the supervision trees.

But practically speaking how does it work under k8s env? When pod is being destroyed, what happens to all the messages sitting there? Pushing state out of actors is a possibility, but isn’t it ruin the whole idea of stateful actors ?