El Teorema de Brewer fue propuesto por Eric Brewer en el año 2000 y demostrado formalmente por Seth Gilbert y Nancy Lynch en 2002.
Establece que en un sistema distribuido no es posible garantizar simultáneamente las tres propiedades siguientes:
C — Consistency (Consistencia)
A — Availability (Disponibilidad)
P — Partition Tolerance (Tolerancia a particiones)
📘 En otras palabras:
Un sistema distribuido solo puede cumplir dos de las tres propiedades al mismo tiempo.
🔹 Las tres propiedades explicadas
1. Consistency (Consistencia)
Todos los nodos del sistema ven los mismos datos al mismo tiempo.
Después de una escritura exitosa, cualquier lectura posterior devuelve el valor más reciente.
📘 Ejemplo:
Si un usuario actualiza su saldo bancario en un nodo, otro usuario que consulta desde otro nodo ve inmediatamente el saldo actualizado.
💡 Equivale a la consistencia de una base de datos relacional tradicional.
2. Availability (Disponibilidad)
El sistema responde a todas las solicitudes, incluso si hay fallos en algunos nodos.
Cada petición recibe una respuesta válida —aunque los datos no siempre sean los más recientes.
📘 Ejemplo:
Un servidor cae, pero otros nodos siguen respondiendo a las consultas, aunque con datos levemente desactualizados.
💡 Se prioriza que el sistema siga funcionando sobre la precisión inmediata de los datos.
3. Partition Tolerance (Tolerancia a Particiones)
El sistema sigue funcionando a pesar de fallos en la comunicación entre nodos.
Una “partición” ocurre cuando los nodos se dividen en grupos que no pueden comunicarse entre sí.
📘 Ejemplo:
Si un centro de datos se desconecta de otro, ambos grupos de nodos continúan procesando solicitudes de sus usuarios locales.
💡 En sistemas distribuidos reales, las particiones son inevitables, por lo tanto P siempre debe cumplirse.
🔹 Las combinaciones posibles (el triángulo CAP)
Dado que P es ineludible en sistemas distribuidos, los diseñadores deben elegir entre priorizar Consistencia (C) o Disponibilidad (A) durante una partición.
| Tipo de sistema | Propiedades | Descripción | Ejemplo |
|---|---|---|---|
| CP (Consistent + Partition Tolerant) | Garantiza consistencia, pero puede sacrificar disponibilidad. | Prefiere bloquear operaciones antes que devolver datos desactualizados. | HBase, MongoDB (modo strong), Google Spanner |
| AP (Available + Partition Tolerant) | Garantiza disponibilidad, aunque puede devolver datos antiguos. | Permite leer/escribir aunque haya inconsistencias temporales. | Cassandra, DynamoDB, CouchDB |
| CA (Consistent + Available) | Teóricamente consistente y disponible, pero no tolera particiones (solo en sistemas centralizados). | Solo posible en bases locales o de un solo nodo. | PostgreSQL, MySQL en una sola máquina |
🔹 Ejemplo práctico
Imaginemos un sistema de ventas distribuido entre dos centros de datos:
Un cliente compra un producto en nodo A.
En ese momento, la red se corta (partición).
Otro cliente consulta el stock en nodo B.
Decisión del sistema:
Si prioriza Consistencia (CP) → bloquea la consulta hasta restablecer la conexión (no hay riesgo de datos incorrectos, pero hay demoras).
Si prioriza Disponibilidad (AP) → responde con el stock viejo (el sistema sigue activo, pero los datos pueden ser inconsistentes).
🔹 Implicancias del teorema CAP
No hay una solución única “mejor”: depende del tipo de aplicación.
En la práctica, se buscan equilibrios dinámicos (por ejemplo, consistencia eventual).
Los sistemas modernos (como los basados en microservicios y nube) tienden hacia AP con mecanismos de sincronización posterior.
🔸 Ejemplo de elección según el caso
| Tipo de sistema | Requiere | Ejemplo de prioridad CAP |
|---|---|---|
| Banca / Finanzas | Precisión absoluta | CP |
| Redes sociales / mensajería | Disponibilidad continua | AP |
| ERP / e-commerce con stock centralizado | Balance intermedio | CP o Eventual Consistency |
| Análisis de logs / métricas | Rendimiento sobre consistencia | AP |
🔹 Consistencia eventual (Eventual Consistency)
Es un modelo intermedio que adoptan muchas bases de datos NoSQL distribuidas:
Los datos pueden estar temporalmente inconsistentes, pero eventualmente todos los nodos convergen al mismo estado.
📘 Ejemplo:
En DynamoDB o Cassandra, una actualización puede tardar unos segundos en propagarse, pero luego todos los nodos mostrarán el mismo valor.
🔹 CAP en bases de datos reales
| Base de Datos | Tipo | Propiedades según CAP |
|---|---|---|
| PostgreSQL / MySQL (1 nodo) | Relacional | CA |
| MongoDB (replicación con write concern) | NoSQL | CP configurable |
| Cassandra | NoSQL | AP |
| Amazon DynamoDB | NoSQL | AP (eventual o strong configurable) |
| Google Spanner | SQL distribuido | CP (usa relojes atómicos para consistencia global) |
| Redis Cluster | In-memory | AP |
🔹 Conclusión
El Teorema de Brewer (CAP) demuestra que no existe un sistema distribuido perfecto:
siempre hay que elegir entre consistencia y disponibilidad en presencia de particiones.
Los ingenieros deben decidir qué propiedad es más crítica según las necesidades del negocio:
CP: si la precisión de los datos es esencial.
AP: si la disponibilidad es más importante.
CA: solo en entornos centralizados o sin distribución.
| Propiedad | Significado | Cuando se prioriza |
|---|---|---|
| C – Consistency | Todos los nodos ven el mismo dato al mismo tiempo | Finanzas, stock crítico |
| A – Availability | Siempre responde, aunque los datos no sean los últimos | Redes sociales, mensajería |
| P – Partition Tolerance | Tolera fallas de comunicación | Necesario en sistemas distribuidos |
| Combinaciones posibles | CP, AP, CA (teórica) | Elección según contexto |
