Pulsas el botón de pago en una tienda en línea y, de repente, el producto que aparecía como «disponible» se agota. Esto ocurre porque otro servidor aún tenía el dato anterior de inventario. Cuando varias computadoras funcionan como un solo servicio, es difícil prometer al mismo tiempo que los datos serán siempre iguales, que todas las solicitudes recibirán respuesta y que la red jamás se interrumpirá. El «teorema CAP (CAP Theorem)» resume este dilema en una línea.
En términos sencillos, el teorema CAP afirma que «en un sistema distribuido es imposible garantizar simultáneamente la consistencia (Consistency), la disponibilidad (Availability) y la tolerancia a particiones (Partition tolerance)». Eric Brewer lo propuso en una conferencia magistral del PODC en 2000, y Seth Gilbert y Nancy Lynch lo demostraron formalmente en 2002.
Este material explica de forma sencilla cómo surgió el teorema CAP, cuál es su definición exacta, qué significan las tres letras C, A y P, por qué es imposible garantizar las tres propiedades a la vez y cómo interpretar el teorema en la práctica.
El teorema CAP y las tres promesas que afrontan los sistemas distribuidos
¿Qué es el teorema CAP?
Un sistema distribuido se compone de varios nodos conectados por una red en lugar de una sola computadora. A medida que crecen servicios como las tiendas en línea, las aplicaciones de mensajería y las bases de datos en la nube, resulta natural repartir los datos entre varios lugares. El problema es que la comunicación entre nodos no siempre funciona a la perfección. Si se corta un cable, la latencia se dispara o algunos servidores dejan de responder, se produce una «partición (Partition)».
Brewer agrupó bajo las siglas C, A y P las tres propiedades que un sistema no puede garantizar simultáneamente en estas condiciones. La idea central es sencilla. Cuando se produce una partición de red, hay que dar prioridad a la consistencia o a la disponibilidad. Se suele resumir con la frase «solo se pueden elegir dos de las tres», pero la interpretación moderna considera la tolerancia a particiones un requisito prácticamente imprescindible y entiende el teorema como una disyuntiva entre C y A.
Para entender el teorema conviene tener presentes los siguientes conceptos.
- Sistema distribuido (Distributed System). Es una estructura en la que varias computadoras colaboran como un solo servicio.
- Nodo (Node). Es cada servidor o proceso que participa en esa colaboración.
- Replicación (Replication). Consiste en copiar los mismos datos en varios nodos.
- Compromiso (Trade-off). Es la relación por la que reforzar una propiedad obliga a ceder en otra.
El significado exacto de las tres letras C, A y P
Expresar las tres letras en lenguaje cotidiano ayuda a aclarar los conceptos.
(1) Consistencia (Consistency)
Es la promesa de que todos los nodos ven el mismo valor más reciente al mismo tiempo. Si en un lugar se reduce el inventario a 1, una consulta realizada inmediatamente después en otro lugar también debe devolver 1. La C de CAP se aproxima a la «consistencia fuerte» de la teoría de bases de datos y se distingue de una consistencia más débil, en la que los valores solo coinciden con el tiempo.
(2) Disponibilidad (Availability)
Es la promesa de que todo nodo que siga operativo responde siempre a las solicitudes. Esto significa que se recibe el resultado de la lectura o la escritura sin fallos ni tiempos de espera agotados, aunque el resultado puede estar desactualizado. Dar una respuesta, aunque tarde, y rechazar por completo la solicitud son decisiones distintas.
(3) Tolerancia a particiones (Partition tolerance)
Es la promesa de que, aunque se interrumpa la comunicación entre los nodos, el sistema sigue funcionando sin detenerse. En la práctica, las particiones son relativamente frecuentes en Internet y en los centros de datos, por lo que a la mayoría de los servicios a gran escala les resulta difícil renunciar a P.
Como analogía, imaginemos que las ventanillas de dos sucursales bancarias solo están conectadas por una línea telefónica. Si al cortarse la comunicación (partición) ambas ventanillas siguen autorizando retiros por separado (disponibilidad), sus saldos pueden dejar de coincidir (pérdida de consistencia). Si suspenden las operaciones para mantener los saldos alineados (conservación de la consistencia), se rechazan las solicitudes de los clientes (pérdida de disponibilidad).
¿Por qué es imposible garantizar las tres propiedades a la vez?
Cuando la red se divide, los grupos de nodos no pueden comprobar el estado más reciente de los demás. En líneas generales, hay dos opciones.
(1) Si se opta por CP
Para preservar la consistencia, hay que impedir las escrituras cuando se desconoce el estado del otro grupo. Por eso se rechazan algunas solicitudes o se dejan en espera. Los datos son correctos, aunque en ese momento puede parecer que el servicio «no responde». Las bases de datos tradicionales basadas en consenso y los sistemas que dan prioridad a la consistencia fuerte tienden a seguir este enfoque.
(2) Si se opta por AP
Para preservar la disponibilidad, cada nodo responde incluso si solo cuenta con su propia información. El servicio sigue disponible, aunque puede mostrar valores distintos hasta que se resuelva la partición. Este enfoque suele combinarse con una estrategia de «consistencia eventual (Eventual Consistency)», que hace coincidir los datos más adelante mediante la sincronización y la resolución de conflictos.
Los manuales también hablan de «sistemas CA», aunque el término se acerca más a una idealización que presupone un entorno en el que jamás se produce una partición. Es posible aproximarse a ese ideal con un solo equipo o un clúster local muy estable, pero en un sistema distribuido a gran distancia resulta difícil ignorar P. Así, frente a la pregunta «¿A cuál de las propiedades C, A y P renunciamos?», lo que se suele preguntar en la práctica es más bien «Cuando se produce una partición, ¿en cuál de las dos propiedades, C o A, cedemos y hasta qué punto?».
Cómo interpretar CAP en la práctica
El teorema CAP ofrece una perspectiva valiosa, aunque su alcance como etiqueta es limitado. El propio Brewer señaló más adelante, en un texto, que el eslogan «2 out of 3» había dado lugar a malentendidos. Para entender los sistemas modernos hacen falta también las siguientes perspectivas.
- Una cuestión de grado. La consistencia y la disponibilidad se sitúan en un espectro, en lugar de funcionar como interruptores que se encienden o se apagan. Es habitual combinar enfoques, por ejemplo, flexibilizando solo la consistencia de las lecturas y manteniendo una consistencia fuerte para las escrituras.
- Relación con la latencia. El modelo PACELC, formulado por Daniel Abadi, plantea que incluso cuando no hay partición (Else) hay que elegir entre latencia (Latency) y consistencia.
- Prioridades según la operación. Los flujos en los que hay dinero en juego, como los pagos y la gestión del inventario, tienden a priorizar C. Los que admiten un pequeño desfase, como los feeds y los recuentos de visualizaciones, tienden a priorizar A.
Quienes diseñan el sistema deben ir más allá de una etiqueta como «nuestro sistema es CP o AP» y especificar qué garantiza cada operación y en qué circunstancias. CAP es un mapa que permite anticipar los límites de un entorno distribuido, más que una ley que elimina opciones.
El teorema CAP no es una advertencia de que «no existe un sistema distribuido perfecto». Es una invitación a reconocer los límites y diseñar un compromiso acorde con las necesidades del negocio. Prever los fallos de comunicación en la red y decidir de antemano cuál de las dos propiedades, consistencia o disponibilidad, se preservará es el primer paso para diseñar un sistema distribuido fiable.
