El análisis de Evgenii Ivanov en The Consensus recorre la replicación por quórum con código Python ejecutable, partiendo del esquema de voto mayoritario de Thomas (1979) para bases de datos replicadas y de la extensión de Gifford ese mismo año, que también dirigía las lecturas a través de quórums. Como dos mayorías siempre se intersectan, dos actualizaciones conflictivas no pueden ser aceptadas a la vez; con n réplicas el sistema tolera floor(n/2) caídas — por eso los factores de replicación suelen ser impares: tres y cuatro réplicas solo toleran una caída.

El artículo construye un registro de quórum simple en Python (clases Register, Replica, TGCluster): las escrituras llevan un timestamp de reloj lógico más ID de réplica, y las lecturas devuelven el valor con el timestamp más alto de una mayoría. Luego demuestra el fallo clásico, conocido de Designing Data-Intensive Applications: una escritura retrasada puede hacer que un lector vea el valor nuevo mientras un lector posterior aún ve el antiguo. No hay noción de commit — una réplica expone el valor en cuanto llega, analogía aproximada con Read Uncommitted —, así que el algoritmo simple no es linealizable.

El algoritmo ABD (Attiya, Bar-Noy, Dolev, años 90) lo corrige con una segunda fase de lectura: tras encontrar el valor más reciente, el lector lo reescribe en un quórum antes de devolverlo, de modo que lecturas posteriores no pueden retroceder. La extensión MWABD de Lynch & Shvartsman (1996) añade soporte multi-escritor mediante una fase de consulta de timestamps antes de escribir. El coste es un round trip de red adicional; el artículo lo contrasta con protocolos basados en líder como Raft o Multi-Paxos, que replican un comando en un solo round trip una vez elegido el líder.

De aquí se derivan dos límites estrictos. Primero, ABD no es compare-and-swap: las réplicas son monótonas en timestamps, así que una escritura obsoleta puede reunir una mayoría de ACKs y ser ignorada silenciosamente — demostrado en código con una escritura tardía que 'tiene éxito' y desaparece. CAS depende de una decisión de orden global sobre el valor actual, que ABD nunca toma; un escenario CAS1/CAS2 muestra a CAS2 triunfar consumiendo un valor que CAS1 repudió. Segundo, ABD no es consenso: colapsa el pasado en el valor con el timestamp más reciente y puede, tras caídas, recuperar el último valor del registro pero no distinguir entradas de log confirmadas de escrituras parciales. Se cita el veredicto de Murat Demirbas: ABD es 'memoryless and hedonistic'.

El eco práctico es Cassandra: su read repair bloqueante refleja el write-back de ABD para lecturas monótonas de quórum, mientras que las operaciones tipo CAS requieren lightweight transactions basadas en Paxos — la misma frontera en producción. El artículo cierra recomendando el libro 'Quorum Systems With Applications to Storage and Consensus' para un tratamiento formal.