Teorema CAP: qué es y por qué importa en bases de datos distribuidas
Teorema CAP
¿Qué es?
El teorema CAP (también llamado teorema de Brewer) afirma que un sistema de datos distribuido —repartido entre varios nodos— no puede garantizar simultáneamente las tres propiedades siguientes: Consistencia, Disponibilidad y tolerancia a Particiones. Ante un fallo de comunicación entre nodos, hay que sacrificar una de ellas.
Es uno de los principios que explica por qué existen tantos tipos de bases de datos y por qué cada una toma decisiones de diseño distintas.
Las tres propiedades
- Consistencia (Consistency): toda lectura devuelve el dato más reciente escrito. Todos los nodos ven la misma información en el mismo instante.
- Disponibilidad (Availability): toda petición recibe una respuesta, aunque algún nodo haya fallado.
- Tolerancia a particiones (Partition tolerance): el sistema sigue funcionando aunque se pierda la comunicación entre partes del clúster.
El compromiso real
En un sistema distribuido las particiones de red son inevitables: tarde o temprano dos nodos dejan de comunicarse. Por eso, en la práctica, la tolerancia a particiones no es opcional y la elección real queda entre consistencia y disponibilidad cuando ocurre esa partición:
- Sistemas CP (consistencia + particiones): ante un corte, prefieren rechazar respuestas antes que devolver datos desactualizados. Encajan donde un dato erróneo es peor que no responder (banca, inventario crítico).
- Sistemas AP (disponibilidad + particiones): ante un corte, siguen respondiendo aunque algún nodo tenga datos ligeramente atrasados, y reconcilian después (consistencia eventual). Encajan en catálogos, redes sociales o telemetría, donde seguir disponible importa más que la exactitud instantánea.
Para qué sirve
- Elegir base de datos con criterio: entender si un motor prioriza consistencia o disponibilidad ayuda a alinearlo con las necesidades del negocio.
- Diseñar arquitecturas realistas: recuerda que no existe el sistema distribuido perfecto; cada decisión tiene un coste.
- Entender la consistencia eventual: muchas bases de datos NoSQL son AP y aceptan un breve desfase a cambio de escalar y no caerse.
Conviene matizar que CAP describe el comportamiento durante una partición. En operación normal, muchos sistemas ofrecen buena consistencia y disponibilidad a la vez; el dilema solo aparece cuando la red falla.
Más información
- NoSQL — muchas de estas bases priorizan disponibilidad (sistemas AP)
- Base de datos relacional — el modelo con consistencia fuerte (ACID) por diseño
- Data streaming — procesamiento de datos en movimiento, donde la partición es un factor constante
- Panorama actual de motores de datos: RDBMS, NewSQL, NoSQL y más — capítulo de la guía práctica de arquitectura de datos de Dataprix.
Para comparar plataformas de datos y su enfoque de consistencia, el directorio de Business Intelligence de Dataprix recoge fichas y análisis editorial.
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.