Skip to main content

Consensus

FlowG rely on the SWIM Protocol (stands for Scalable Weakly Consistent Infection-style Process Group Membership) for node discovery.

It is a "gossip" protocol that enables nodes to join and leave the cluster and become aware of eachother.

In terms of the CAP theorem, SWIM is "AP", it sacrifices strong consistency for availability and partitioning tolerance.

NB: FlowG achieves eventual consistency using a CRDT. For more information, consult this page.

Why not Raft?​

Raft is a distributed consensus protocol. Unlike FlowG's "SWIM+CRDT" architecture, it is (in terms of CAP theorem) "CP", it favors strong consistency and partitioning tolerance over availability.

Raft is a leader/follower protocol, it tries to elect a leader node. All writes must be done on the leader node, which means:

  • when leader election fails, the cluster becomes unavailable
  • when a write is sent to a node, it must redirect it to the leader node, increasing latency
  • since all writes must be directed to a single node, its load increase
  • since all writes must have a quorum to be accepted (which implies back-and-forth between the leader and followers), performance can be degraded

High Availability and Performance are key concerns, which makes Raft not suited for our usecase.

Why not Paxos?​

Similarly to Raft, Paxos protocols are (in terms of CAP theorem) "CP". Which means the cluster can become unavailable.