Por qué los sistemas distribuidos no pueden tenerlo todo

Los sistemas distribuidos modernos se basan en concesiones. El rendimiento, la fiabilidad, la escalabilidad y la coherencia no son gratuitos: siempre hay que pagar un precio. Ahí es donde entra en juego el teorema CAP: es el punto de partida para comprender los compromisos inevitables en el diseño distribuido.

¿Por qué es cierto el teorema CAP? ¿Qué explica realmente? Y, lo más importante, ¿es suficiente? En este artículo, exploraremos el teorema CAP, sus limitaciones, las críticas que ha enfrentado y cómo las ideas más nuevas como PACELC están impulsando el debate. Profundicemos.

Teorema CAP

La primera versión del teorema CAP comenzó como un debate entre ACID y BASE . Pero con el tiempo evolucionó, obtuvo una prueba formal y se convirtió en el teorema CAP tal como lo conocemos hoy.

El teorema CAP establece que un sistema distribuido puede satisfacer como máximo dos de tres propiedades simultáneamente :

• Consistencia
• Disponibilidad
• Tolerancia de partición

Esta limitación obliga a los ingenieros a hacer concesiones difíciles en función de los objetivos del sistema y las realidades de sus entornos distribuidos.

Consistencia

La consistencia en CAP no es lo mismo que la consistencia en las transacciones ACID . En el teorema CAP se refiere a linealización o consistencia fuerte . Significa que todos los nodos en un sistema distribuido deben presentar siempre una vista única y actualizada de los datos , independientemente de qué nodo procese la solicitud. Esto significa que cada operación de lectura refleja la escritura más reciente, sin importar qué nodo consulte.

💡 Por otro lado, la coherencia en ACID se centra en garantizar que una transacción lleve la base de datos de un estado válido a otro estado válido, siguiendo las reglas definidas por el esquema de la base de datos. Se trata más bien de aplicar restricciones de integridad (como claves externas, restricciones únicas, etc.) y garantizar que la base de datos no quede en un estado no válido, incluso en caso de fallos.

Disponibilidad

La disponibilidad en CAP significa que cada nodo que no falla debe devolver una respuesta para cada solicitud que recibe, independientemente de las particiones de la red . En otras palabras, si un nodo en buen estado recibe una solicitud, debe procesarla y responderla. Sin embargo, CAP no garantiza que la respuesta siempre sea "correcta" o esté actualizada ; solo garantiza que el nodo no falle de manera silenciosa (por ejemplo, en un sistema AP , los nodos pueden responder con datos obsoletos durante una partición para garantizar la disponibilidad).

💡 Eric Brewer (el autor original de CAP) describió originalmente esta propiedad de forma un poco más flexible: "casi todas las consultas deberían obtener una respuesta". Sin embargo, en la prueba formal de CAP, la disponibilidad se hizo más estricta y se requirió que "todas las consultas reciban una respuesta siempre que el nodo que las maneja esté en buen estado".

En la práctica, sin embargo, la disponibilidad no es una garantía absoluta; a menudo depende de restricciones específicas del sistema, como el tiempo que está dispuesto a esperar para recibir una respuesta. En los sistemas del mundo real, el tiempo de respuesta (o los tiempos de espera) desempeña un papel fundamental a la hora de determinar el SLA (acuerdo de nivel de servicio), aunque el CAP en sí no tenga en cuenta directamente la latencia. Más información al respecto en esta publicación del blog .

Tolerancia de partición

La tolerancia a las particiones tiene que ver con la supervivencia ante fallas de red. Si los nodos no pueden comunicarse debido a una división de la red (partición), el sistema debe cumplir con sus garantías de consistencia o disponibilidad, según sus opciones de diseño. Una partición se produce cuando los nodos no pueden comunicarse debido a paquetes perdidos, tiempos de espera agotados o divisiones de la red.

Los sistemas distribuidos no viven en un mundo de cuento de hadas con redes perfectas. Los paquetes se descartan, se agotan los tiempos de espera y los picos de latencia son inevitables. Por este motivo, la tolerancia a las particiones no es negociable en ningún sistema distribuido : las particiones se producirán tarde o temprano, por lo que no se puede "elegir" ignorarlas, por muy tentador que pueda parecer.

En CAP, la tolerancia a particiones no significa que el sistema siga funcionando como si nada hubiera pasado, sino que el sistema debe decidir si priorizar la disponibilidad (AP) o la consistencia (CP) durante una partición. Si ignorara la tolerancia a particiones, básicamente estaría construyendo un sistema monolítico no distribuido.

La PAC explicada

La forma más sencilla de entender el CAP es considerar una partición de red , una situación en la que dos partes de un sistema distribuido no pueden comunicarse entre sí. En tal escenario, el sistema se enfrenta a tres posibles resultados:

1. Si una parte del sistema acepta actualizaciones mientras que la otra está aislada, las dos partes tendrán estados inconsistentes. Esto da como resultado una pérdida de C (Consistencia) .
2. Si el sistema decide mantener la coherencia , debe bloquear las actualizaciones en una o ambas partes de la partición para garantizar un estado unificado en todos los nodos. Esto genera una pérdida de A (disponibilidad) porque algunas solicitudes se rechazarán o retrasarán indefinidamente.
3. Si el sistema elige permanecer disponible (A) y consistente (C) sin tolerar la partición (P), no está verdaderamente distribuido. Esto requeriría que los nodos interactúen y concilien el estado, lo cual es imposible durante una partición.

Por lo tanto, durante una partición , el sistema solo puede satisfacer dos de las tres propiedades (C, A o P) . Una vez que se resuelve la partición (es decir, los nodos vuelven a interactuar), el sistema puede recuperar las tres propiedades, pero durante la partición en sí , las compensaciones son inevitables.

Implicaciones del teorema

Una consecuencia del teorema para sistemas asincrónicos es que solo son posibles tres combinaciones de consistencia, disponibilidad y tolerancia de partición:

AP (Disponibilidad + Tolerancia de partición)

Los sistemas de este tipo responden a las consultas, pero los datos devueltos pueden no estar siempre actualizados, con actualizaciones más lentas de los datos pero "siempre" disponibles. Ejemplos de este tipo de sistemas son DNS, DynamoDB y Cassandra.

CP (Consistencia + Tolerancia de partición)

Los sistemas de este tipo siempre devuelven datos actualizados, pero algunos nodos del sistema, o incluso todos, pueden no responder si se dividen en particiones. Ofrece actualizaciones atómicas, pero puede provocar tiempos de espera agotados. Las bases de datos NoSQL, como Google BigTable, MongoDB, HBase y Redis, son todas sistemas de este tipo.

CA (Consistencia + Disponibilidad)

Los sistemas de este tipo siempre devuelven datos actualizados cuando no hay particiones. Debido a esta última limitación, normalmente, estos sistemas se utilizan solo en una máquina. Un ejemplo son las bases de datos relacionales clásicas.

En realidad, elegimos entre CP y AP porque CA es básicamente un monolito sin particiones. Para sistemas de gran escala, los diseñadores no pueden abandonar P y, por lo tanto, tienen una elección difícil entre C y A.

En CA, la falla de un nodo significa la indisponibilidad total del servicio. Pero esto no deshabilita la escalabilidad, ya que podemos clonar monolitos independientes y distribuir la carga entre ellos.

Crítica del teorema CAP

El teorema CAP ha sido un concepto fundamental en los sistemas distribuidos, pero no está exento de limitaciones. A pesar de su claridad a la hora de presentar la idea de las compensaciones, el teorema CAP ha sido criticado a menudo por simplificar en exceso realidades complejas, lo que ha dado lugar a malentendidos y aplicaciones incorrectas.

1. Las compensaciones sólo se aplican durante las particiones

Una de las críticas más comunes es que las disyuntivas del teorema CAP (elegir entre consistencia (C) y disponibilidad (A)) solo se aplican cuando realmente se produce una partición de la red (P) . En un funcionamiento normal, cuando la red es estable y no existen particiones, no existe una disyuntiva inherente entre consistencia y disponibilidad.

Además, estas compensaciones no son universales en todo el sistema. Dentro del mismo sistema distribuido:

• Diferentes partes del sistema pueden experimentar diferentes compensaciones según el contexto (como la ubicación del usuario o el tipo de datos).
• Algunas operaciones pueden priorizar la consistencia mientras que otras priorizan la disponibilidad.
• Las decisiones pueden variar en tiempo de ejecución dependiendo de factores como la carga, la latencia o los requisitos del usuario.

Este matiz a menudo se pierde en los debates de alto nivel sobre CAP, lo que lleva a clasificaciones demasiado simplificadas de los sistemas como "CP" o "AP" en general.

2. CAP ignora la latencia

Otra crítica importante es que el teorema CAP no tiene en cuenta la latencia , aunque en la práctica la latencia y la partición están profundamente conectadas. Por ejemplo:

• Una red lenta (alta latencia) puede parecer indistinguible de una partición.
• Los tiempos de espera (que se utilizan para detectar fallas) son subjetivos y dependen en gran medida del diseño del sistema y de las condiciones de la red. Lo que un sistema define como una "partición" puede ser simplemente un retraso transitorio para otro.

En sistemas distribuidos del mundo real, cuando se produce una partición o una latencia alta, el sistema debe tomar una decisión dentro de un período de tiempo de espera : priorizar la disponibilidad devolviendo un resultado posiblemente obsoleto, o priorizar la consistencia esperando más tiempo (y posiblemente no respondiendo). La vista binaria de CAP no captura la complejidad de estas decisiones.

3. Las propiedades CAP no son binarias

El teorema CAP presenta la consistencia, la disponibilidad y la tolerancia a la partición como propiedades binarias: se tienen o no se tienen. Pero en la práctica, las tres propiedades existen en un espectro :

• La disponibilidad no es una propiedad binaria de "activación/desactivación": varía entre el 0 % y el 100 %. Por ejemplo, un sistema puede garantizar una disponibilidad del 99,99 %, pero eso permite pequeños períodos de indisponibilidad.
• La coherencia tiene distintos niveles, desde la coherencia eventual hasta la coherencia causal y la coherencia fuerte. No todas las aplicaciones requieren linealización completa.
• La tolerancia a particiones en sí no es un evento claro y definido. Los sistemas pueden no estar de acuerdo sobre si existe una partición (por ejemplo, un nodo considera que un tiempo de espera es un error, mientras que otro continúa funcionando normalmente).

Esta naturaleza continua de las propiedades hace que CAP sea demasiado simplista para modelar las complejidades de los sistemas distribuidos modernos.

Teorema PACELC

Si bien el CAP revolucionó nuestra comprensión de las compensaciones en los sistemas distribuidos, no es la última palabra sobre el tema. El teorema PACELC descrito por Daniel J. Abadi se considera un enfoque alternativo para el diseño de sistemas distribuidos. Se basa en el modelo CAP, pero además de la consistencia, la disponibilidad y la tolerancia a las particiones, también incluye la latencia y la exclusión lógica entre combinaciones de estos conceptos.

PACELC introduce dos modos de funcionamiento distintos para sistemas distribuidos:

1. Modo de partición ( PAC ): ¿Qué compensación hace el sistema cuando se produce una partición? Aquí, volvemos a analizar la compensación CAP clásica entre disponibilidad (A) y consistencia (C) .
2. Modo Else ( ELC ): ¿Qué compensación hace el sistema cuando no hay partición y la red funciona normalmente? En este modo, el sistema se enfrenta a una compensación diferente: entre latencia (L) y consistencia (C) .

El equilibrio entre latencia y consistencia

Si bien las particiones son inevitables en los sistemas distribuidos, son poco frecuentes en comparación con los desafíos que surgen durante el funcionamiento normal. En los sistemas distribuidos modernos, la latencia suele ser un cuello de botella más grande que las particiones de red, en particular para aplicaciones a escala global. Aquí es donde se centra PACELC : abordando las desventajas que se producen cuando el sistema funciona sin particiones. A diferencia de CAP, que se centra únicamente en el comportamiento durante escenarios de falla, PACELC enfatiza las decisiones que los arquitectos deben tomar todos los días para equilibrar la latencia (L) y la consistencia (C) :

• Una coherencia sólida requiere coordinación y sincronización entre nodos para mantener una vista unificada de los datos. Esta sobrecarga genera demoras y reduce los tiempos de respuesta.
• Los sistemas de baja latencia (como los que adoptan la consistencia eventual) priorizan la velocidad al relajar las garantías de consistencia. Estos sistemas responden más rápido, pero ocasionalmente pueden devolver datos obsoletos o inconsistentes.

Al ampliar la conversación más allá de las particiones para incluir el funcionamiento normal, PACELC garantiza que el rendimiento diario de los sistemas distribuidos se trate con la importancia que merece.

Envolviéndolo

La formulación del teorema CAP ha sido un acontecimiento significativo en la comunidad, y los estudios sobre su impacto en el diseño de sistemas distribuidos han demostrado que los diseñadores de sistemas distribuidos no deben limitar el sistema a dos propiedades, sino que deben esforzarse por maximizar las garantías requeridas en cada caso particular. Para ello, es razonable dividir el sistema en segmentos, cada uno de los cuales tiene sus propios requisitos, y diseñar el sistema en función de los requisitos de cada uno de los segmentos.

El teorema CAP ha sido una piedra angular del pensamiento de sistemas distribuidos durante décadas. Nos brindó un marco para razonar sobre las compensaciones inherentes de la consistencia, la disponibilidad y la tolerancia a las particiones. Pero, en muchos sentidos, es una simplificación de la realidad, que supone opciones binarias e ignora factores críticos como la latencia.

PACELC se basa en el CAP, reconociendo que:

• Existen compensaciones incluso cuando no existen particiones.
• La latencia es una preocupación de primera clase en el diseño de sistemas distribuidos.

Tanto CAP como PACELC son herramientas valiosas, pero ninguna de ellas es una receta paso a paso para construir sistemas. En cambio, proporcionan modelos mentales para evaluar las ventajas y desventajas y comprender los límites de las arquitecturas distribuidas.

Materiales adicionales

• La PAC doce años después: cómo han cambiado las "reglas"
• Cassandra: La guía definitiva
• Por favor, dejen de llamar a las bases de datos CP o AP y Una crítica del teorema CAP por Martin Kleppmann
• Notas sobre sistemas distribuidos para jóvenes

¡Gracias por leer!

¿Tienes curiosidad sobre algo o tienes ideas para compartir? ¡Deja tu comentario a continuación! Echa un vistazo a mi blog o sígueme a través de LinkedIn , Substack o Telegram .