L'article d'Evgenii Ivanov sur The Consensus explore la réplication par quorum avec du code Python exécutable, en partant du vote majoritaire de Thomas (1979) pour les bases répliquées et de l'extension de Gifford la même année, qui faisait aussi passer les lectures par un quorum. Comme deux majorités se recoupent toujours, deux mises à jour conflictuelles ne peuvent être acceptées toutes les deux ; avec n répliques, le système tolère floor(n/2) pannes — d'où les facteurs de réplication impairs : trois et quatre répliques ne tolèrent qu'une seule panne.

L'article construit un registre à quorum simple en Python (classes Register, Replica, TGCluster) : les écritures portent un timestamp combinant horloge logique et identifiant de réplique, et les lectures retournent la valeur au timestamp le plus élevé d'une majorité. Il démontre ensuite le défaut classique, connu de Designing Data-Intensive Applications : une écriture retardée peut laisser un lecteur voir la nouvelle valeur tandis qu'un lecteur ultérieur voit encore l'ancienne. Il n'y a pas de notion de commit — une réplique expose la valeur dès réception, analogue approximatif du Read Uncommitted —, l'algorithme simple n'est donc pas linéarisable.

L'algorithme ABD (Attiya, Bar-Noy, Dolev, années 1990) corrige cela avec une seconde phase de lecture : après avoir trouvé la valeur la plus récente, le lecteur la réécrit dans un quorum avant de la retourner, empêchant tout retour en arrière. L'extension MWABD de Lynch & Shvartsman (1996) ajoute le multi-writer via une phase d'interrogation des timestamps avant l'écriture. Le coût est un aller-retour réseau supplémentaire, que l'article compare aux protocoles à leader comme Raft ou Multi-Paxos, qui répliquent une commande en un seul aller-retour une fois le leader établi.

Deux limites strictes en découlent. D'abord, ABD n'est pas un compare-and-swap : les répliques sont monotones en timestamps, donc une écriture obsolète peut quand même récolter une majorité d'ACK tout en étant silencieusement ignorée — démontré en code avec une écriture tardive qui 'réussit' puis disparaît. Le CAS dépend d'une décision d'ordonnancement global sur la valeur courante, qu'ABD ne prend jamais ; un scénario CAS1/CAS2 montre CAS2 réussir en consommant une valeur que CAS1 a désavouée. Ensuite, ABD n'est pas un consensus : il écrase le passé sur la valeur au timestamp le plus récent et peut, après des pannes, retrouver la dernière valeur du registre mais pas distinguer les entrées de log validées des écritures partielles. Le verdict de Murat Demirbas est cité : ABD est 'memoryless and hedonistic'.

L'écho pratique est Cassandra : son read repair bloquant reflète le write-back d'ABD pour des lectures monotones, tandis que les opérations de type CAS exigent des lightweight transactions fondées sur Paxos — la même frontière en production. L'article recommande en conclusion 'Quorum Systems With Applications to Storage and Consensus' pour un traitement formel.