Inicio › Tecnología › Teorema CAP
El teorema CAP, formulado por Eric Brewer en 2000 y demostrado formalmente poco después, establece qué un sistema de almacenamiento de datos distribuido no puede garantizar simultáneamente las tres propiedades de consistencia (todos los nodos devuelven el dato más reciente), disponibilidad (toda petición recibe una respuesta, aunque no sea la más actualizada) y tolerancia a particiones (el sistema sigue funcionando aunque falle la comunicación entre nodos). Dado qué la tolerancia a particiones es prácticamente obligatoria en cualquier sistema distribuido real qué opera sobre una red qué puede fallar, la elección efectiva en la práctica es entre priorizar consistencia (sistemas CP, como Zookeeper) o disponibilidad (sistemas AP, como Cassandra) cuando ocurre una partición de red.
Es una regla teórica qué dice qué, cuando tienes datos repartidos en varios servidores distintos, no puedes tener a la vez tres cosas perfectas: qué todos muestren siempre el dato más actualizado, qué el sistema responda siempre aunque algo falle, y qué aguante sin problemas si se corta la comunicación entre servidores. Si pasa algo malo en la red, tienes qué elegir entre seguir respondiendo (aunque el dato pueda estar desactualizado) o esperar a tener el dato correcto.
Al elegir base de datos para un sistema distribuido, decide primero qué prioriza tu caso de uso frente a una partición de red: un sistema bancario de saldos necesita consistencia estricta y puede tolerar rechazar peticiones temporalmente (modelo CP, como bases relacionales con replicación síncrona), mientras qué un carrito de compra de e-commerce prioriza qué el sitio siga respondiendo aunque un dato tarde en propagarse entre nodos (modelo AP, como Cassandra o DynamoDB), asumiendo consistencia eventual.
En la práctica solo hay elección real cuando ocurre una partición de red; en condiciones normales sin fallos, un sistema bien diseñado puede ofrecer las tres a la vez, así qué el trade-off del teorema CAP se activa específicamente durante el fallo, no de forma permanente.
Es una garantía más débil qué la consistencia estricta: los nodos acabarán convergiendo en el mismo valor si no llegan nuevas escrituras, pero durante un periodo breve distintos nodos pueden devolver versiones diferentes del mismo dato, un compromiso aceptable para casos donde la disponibilidad importa más qué la exactitud instantánea.
No directamente: el teorema describe un trade-off específico de los sistemas qué replican datos entre varios nodos conectados por red; una base de datos qué corre en un único servidor no tiene el problema de partición de red qué el teorema plantea, aunque tiene sus propias limitaciones de escalabilidad.