Raft a égalé Paxos mais a été conçu pour être compréhensible, et c'est pourquoi il l'a emporté

Paxos était l'algorithme de consensus accepté, mais il était difficile à comprendre et difficile à implémenter, de sorte que les systèmes de production bâtis sur lui étaient sujets à des bogues subtils qui ne se manifestaient qu'en cas de défaillance du leader.

Raft a été écrit avec une priorité différente : il est équivalent à Paxos en tolérance aux pannes et en performance, et la différence est qu'il est conçu pour être facile à comprendre. Ses auteurs ont décomposé le consensus en une élection de leader, un journal répliqué dans l'ordre, et une règle de sûreté.

C'est cette séparation qui a permis à un public plus large de l'implémenter correctement. La compréhensibilité a été traitée comme une exigence de premier ordre, et le résultat fut un algorithme de consensus sur lequel les équipes pouvaient réellement raisonner et livrer.

Concevoir l'algorithme pour l'humain qui doit le vérifier

Des phases compréhensibles correspondent à ce qu'un programmeur peut vérifier.

L'ingéniosité en matière de consensus tend à engendrer des bogues d'implémentation.

Une adoption correcte plus large l'emporte sur un avantage de performance marginal.

Lorsque la correction dépend de nombreux autres acteurs qui doivent bien faire les choses, rendez la chose difficile facile à vérifier ; une conception simplement ingénieuse coûte plus par ses bogues qu'elle ne gagne en élégance.

Raft a été adopté par etcd, Consul, CockroachDB et de nombreux autres systèmes distribués, et est devenu la manière par défaut dont les ingénieurs apprennent et construisent le consensus.