Summary: Consistent, Distributed Elixir - ElixirDaze 2018


When building distributed systems there are two binary points at the end of the spectrum:

  • always available systems (AP)
  • always consistent systems. (CP)

If you want an always available system you can use phoenix presence, as you know for the title, the talk focused on consistent systems.

Let’s recap the CAP theorem:

When partitioned a distributed system can be always available (but inconsistent for a while) or always consistent (but not always available)

The important thing about both of these is they eventually get the other property as well when the nodes are connected. (AP becomes consistent and CP becomes available).

Raft is a consensus protocol for building consistent state machines in a cluster. It was built as an alternative to Paxos.

In this protocol there are only two kind of nodes, a leader and followers. The leader is the one that is responsible for being in contact with its followers, and the way it does this is by sending a signal (heartbeat) every 150ms to make sure the connection works and that he stays being the leader.

If the followers don’t get this heartbeat, they each have an internal clock (timeout) that will change the current node into a candidate and send a message to all the nodes it can connect to that it’s a candidate so an election is held up and if he’s got the majority of nodes then it becomes the new leader.

So the author built an elixir implementation of the Raft protocol (CP) which you can find here: https://github.com/toniqsystems/raft

And there’s also this implementation of the protocol by the RabbitMQ team: https://github.com/rabbitmq/ra

Special thanks

to Chris Keathley the content above is from his talk at Elixir Daze 2018, get more from him on his blog.