Explica el teorema CAP con un ejemplo concreto de qué pasa durante una partición de red
Las particiones no son opcionales en un sistema distribuido — CAP en realidad describe qué te ves obligado a sacrificar en el instante en que ocurre una.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Explica el teorema CAP con un ejemplo concreto de qué pasa durante una partición de red
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#El teorema, con precisión
CAP dice que un sistema de datos distribuido solo puede garantizar dos de tres propiedades a la vez:
- Consistencia (en este contexto: linealizabilidad — toda lectura ve la escritura más reciente, como si solo existiera una copia del dato)
- Disponibilidad — toda petición a un nodo que no falló recibe una respuesta (no un error, no un timeout)
- Tolerancia a particiones — el sistema sigue funcionando incluso cuando la red pierde mensajes entre nodos
La parte que la gente responde mal en entrevistas: la tolerancia a particiones no es realmente una elección. Las redes se particionan — se cortan cables, fallan switches, se congestionan enlaces entre regiones — sin importar si tu arquitectura "eligió" tolerarlo o no. Así que CAP no es un menú de tres opciones donde eliges dos; es una afirmación sobre qué te ves obligado a sacrificar en el momento en que ocurre una partición real. En operación normal, sin partición, puedes tener consistencia y disponibilidad al mismo tiempo. El teorema solo muerde cuando la red está rota, y en ese momento debes elegir: mantenerte consistente (rechazando algunas peticiones) o mantenerte disponible (aceptando el riesgo de devolver datos desactualizados o en conflicto).
#Un ejemplo concreto: inventario en dos centros de datos
Imagina un sistema de e-commerce con una base de datos replicada entre dos centros de datos, US-East y EU-West, y exactamente una unidad de un artículo de edición limitada en stock. Una partición de red corta el enlace entre los dos centros de datos — ambos siguen funcionando y son alcanzables por sus usuarios locales, simplemente no pueden hablar entre sí.
Un cliente en Estados Unidos y un cliente en Europa hacen clic en "comprar" en el mismo segundo.
Si el sistema elige CP (consistencia sobre disponibilidad): cada centro de datos, incapaz de confirmar con el otro lado que el artículo todavía está disponible, se niega a completar la compra en vez de arriesgarse a venderlo dos veces — o el sistema exige que una mayoría/quórum de nodos esté de acuerdo, y el lado minoritario (el centro de datos que no puede alcanzar suficientes pares) rechaza todas las escrituras y devuelve un error a sus usuarios hasta que la partición se resuelva. Un cliente, o ambos, ve un error de "por favor intenta de nuevo." Frustrante, pero a nadie se le cobra por una unidad que no existe.
Si el sistema elige AP (disponibilidad sobre consistencia): cada centro de datos completa la venta de forma independiente usando solo su copia local de los datos, porque rechazar la petición no es aceptable. Ambos clientes reciben un correo de "pedido confirmado." Cuando la partición se resuelve y los dos centros de datos se reconcilian, el sistema descubre que vendió la misma unidad dos veces y ahora tiene que resolver ese conflicto después del hecho — cancelar un pedido, disculparse, acelerar una reposición, lo que decida el negocio.
Ninguna de las dos elecciones es "correcta" en abstracto — depende por completo de qué es más costoso para ese negocio en particular: que un cliente vea un mensaje de error, o que un cliente reciba un correo de disculpas por un artículo vendido de más.
#Dónde se ubican los sistemas reales
- Sistemas que favorecen CP: RDBMS tradicionales configurados con replicación síncrona o un único primario de escritura, ZooKeeper, etcd, HBase. Típicamente prefieren rechazar una petición antes que devolver una respuesta incorrecta, lo cual encaja con datos de configuración, elección de líder y libros contables financieros.
- Sistemas que favorecen AP: Cassandra, DynamoDB (en su configuración por defecto), Riak. Prefieren responder siempre, y después reparar la inconsistencia con mecanismos como read repair, vector clocks, o last-write-wins — lo cual encaja con carritos de compra, datos de sesión y feeds sociales, donde una respuesta desactualizada es mucho más barata que una falla dura.
#Más allá de CAP: PACELC
CAP solo describe el comportamiento durante una partición. La extensión PACELC (Daniel Abadi) señala que incluso cuando no hay partición, igual estás intercambiando latencia por consistencia — un sistema que quiere consistencia fuerte tiene que esperar a que un quórum de réplicas (a menudo entre regiones) confirme antes de responder, mientras que un sistema que acepta consistencia eventual puede responder al instante desde la réplica local más cercana. Así que el planteo más completo es: si hay Partición, elige entre Availability (disponibilidad) o Consistencia; Else (en operación normal), elige entre Latencia o Consistencia. Por eso decir "nuestro sistema es AP" o "nuestro sistema es CP" en realidad solo describe la mitad de su comportamiento real.
🧠 Check your understanding
0/1 · 0/1 answered1. Durante una partición de red activa, ¿entre qué dice el teorema CAP que debes elegir?