|
What you describe sounds more like Orleans grains. Erlang's lightweight processes serve a different purpose than actors or objects, they're really about fault tolerance. A typical Phoenix app spawns one process for every HTTP request, websocket channel, or DB connection, for example. All these things have a lifetime shorter or equal to the pod's. The VM gives guarantees and tools to ensure one of these process crashing will not affect the others, unless you want it to. For instance, if a request crashes, its memory will be reclaimed, open files will be closed, DB connections will be re-opened, the exit reason will be logged, error metrics incremented, etc. This is possible with no defensive programming like try/catch and so on, because the processes are isolated. For example they don't share memory, so it's always safe to deallocate something if its owner process died. This gives a two-layer safety net that allows for very reliable apps, where the VM protects you against bugs in your own code, and Kubernetes protects you against bugs in Erlang, or really catastrophic failures. There's a good blog post on this: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-... |
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”