Sorry for the dummy question, but I wonder when do we need distributed applications to be stateful while we have databases that already does replication and is consistent? There some examples when to use state that needs to be replicated to other nodes? Because with all that buzz of microservices got me thinking, because most of the time is just incoming data that we shove into a database no matter how many instances of that service is running.
2 Likes
It would be a bad idea to mimic what database are good at with distributed nodes… but sometimes the source of truth is not the db. It’s just more efficient when you don’t need to encode/decode data and keep it into processes.
For example when the state is ephemeral, like the state of a game, or a chat. With websockets, You can talk to the server directly, You would not want to persists this communication into db.
When using Rails, I had the bad habit to design system around database.
With Elixir, You have plenty of options (processes, ets, dets, mnesia, etc). And the possibility to use term_to_binary, binary_to_term to persists any complex structures into almost anything.
See this post.
10 Likes
Indeed, I think I was trying to find a excuse to shove distributed nodes into Elixir, but it clicked me something, maybe just because Erlang has easy distribution it doesn’t mean that I have to use it just because it’s there, but I would use the language because when needed I can leverage that without going to search outside to a solution, so it allow us to start simple but knowing that we will not be left empty handed when things grow, and the same goes to storing state and data, or even NIFs, you start small and then scale til crazy macros!
2 Likes
