7 years in on an elixir startup that has well over a thousand active paid accounts using our system every day to run critical businesses. I have to politely disagree.
USE OBAN from day one for any kind of background jobs. do not trust genservers. they lose their state if a pod goes. There's no retry logic built in.
> Start there and only use Oban if there's some form of consistency/resumability guarantee that you need.
oban is easy enough to integrate. it takes like 10 min of your time and you get a LOT out of the box. use genservers if you're running ephemeral servers but if you are creating background tasks, absolutely use oban for anything you plan to put on production.
Oban is such an easy value proposition to justify. consider it as important to learn as core phoenix
sounds like you are using Elixir on Kubernetes. What is the experience and the reasoning with this? I was thinking about this and read on many blogs that it is somehow redundant because Kubernetes implements something like "let it crash" on its own when it's already an Erlang/OTP/Beam concept.
Kubernetes handles let it crash at the process level. so we have one erland vm running inside a docker container and it is the only tennant on its individual machine. this is managed by kubernetes. kubernetes also exposes a discovery endpoint so that all the erland vms we have can be aware of each other and form a cluster. IF something takes down the erlang vm (its exceedingly rare but it does happen), kubernetes will bring up a new one.
erlang's let it crash apply to its lightweight processes which are really just fancy threads with a vm specific scheduler and heap allocation. if somethign crashes a genserver, erlang handles it.
TLDR: they compliment each other
If Kubernetes is not involved, passing messages between Elixir nodes is easy. We just need the name of thr node (and a cookie, if needed).
Not sure if that is possible inside a Kube cluster.