CAP Theorem

Resumen

El teorema CAP, formulado por Eric Brewer en 2000 y probado formalmente por Gilbert y Lynch en 2002, establece que un sistema distribuido que comparte datos solo puede garantizar simultáneamente dos de estas tres propiedades:

• Consistency (C): todos los nodos ven los mismos datos al mismo tiempo. Una lectura después de una escritura siempre devuelve el valor más reciente.
• Availability (A): el sistema siempre responde a las solicitudes, incluso si algunos nodos están caídos. Cada request recibe una respuesta —no necesariamente el dato más reciente—.
• Partition Tolerance (P): el sistema sigue funcionando a pesar de que la red divida a los nodos y se pierdan mensajes entre ellos.

La P —tolerancia a particiones— no es negociable en sistemas distribuidos reales: las redes fallan, los switches se rompen, los cables se cortan. Por lo tanto, la elección real es entre C y A cuando ocurre una partición: ¿prefiero devolver datos consistentes aunque algunos requests fallen, o prefiero seguir respondiendo aunque los datos puedan estar desactualizados?

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Un grupo de amigos organizando una cena por WhatsApp. Si hay conexión, todos están de acuerdo en el menú —consistencia—. Si uno se queda sin batería, el resto tiene que decidir: seguir adelante y decidir sin él —disponibilidad sobre consistencia: el menú puede cambiar cuando él vuelva—, o esperar hasta que todos estén conectados —consistencia sobre disponibilidad: la cena se retrasa—. El teorema CAP dice que cuando alguien se desconecta —partición—, no podés tener ambas cosas a la vez.

Uso práctico

Los sistemas se clasifican según qué propiedad sacrifican durante una partición:

| Tipo | Sacrifica | Ejemplos | |---|---|---| | CP | Disponibilidad | HBase, MongoDB (configurable), sistemas bancarios | | AP | Consistencia | Cassandra, DynamoDB, CouchDB, DNS | | CA | Tolerancia a particiones | Sistemas que no son distribuidos (una sola máquina) |

La mayoría de las bases de datos modernas no son CP o AP puras: permiten configurar la consistencia por operación. DynamoDB y Cassandra ofrecen lecturas consistentes con quorum, sacrificando disponibilidad parcial. Spanner usa relojes atómicos para ofrecer consistencia fuerte global sin perder demasiada disponibilidad.

Ejemplo trabajado: elegir CP o AP según el caso de uso

Un sistema tiene dos funcionalidades: un catálogo de productos y un sistema de reservas con cupo limitado. Para el catálogo, el equipo elige DynamoDB en modo eventualmente consistente —AP—: si un producto se actualiza, algunos usuarios ven la versión anterior unos segundos, pero el sistema siempre responde. Para las reservas, el equipo elige DynamoDB con lecturas fuertemente consistentes —CP—: cuando quedan 2 cupos y dos usuarios compran al mismo tiempo, el sistema garantiza que solo uno se lleva el cupo, aunque la latencia sea mayor.

Evidencia

• Wikipedia, CAP theorem explica la formulación original de Brewer, la prueba de Gilbert y Lynch, y cómo el teorema influye en el diseño de bases de datos distribuidas.