Cuando los datos se reparten y replican entre varios nodos, surge una pregunta fundamental: ¿podemos garantizar a la vez que todas las lecturas vean el dato más reciente, que el sistema responda siempre y que tolere fallos de red? El Teorema CAP demuestra que no: hay que elegir. Comprender esta concesión es esencial para diseñar el almacenamiento de datos de cualquier sistema distribuido, y para elegir correctamente entre las decenas de bases de datos disponibles hoy.

En esta lección estudiaremos el Teorema CAP, su refinamiento PACELC, la diferencia entre consistencia fuerte y eventual, y clasificaremos las bases de datos más comunes según las garantías que ofrecen.

1. Las tres propiedades: C, A y P
2. El enunciado del Teorema CAP
3. Por qué P no es opcional en la práctica
4. CP frente a AP: la elección real
5. PACELC: más allá de CAP
6. Consistencia fuerte frente a eventual
7. Tabla de bases de datos según CAP
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

El Teorema CAP, formulado por Eric Brewer, habla de tres propiedades de un sistema de datos distribuido:

Cuidado: la "Consistencia" de CAP no es la "C" de ACID. Aquí significa que todas las réplicas coinciden, no la integridad transaccional.

El teorema afirma:

En presencia de una partición de red, un sistema distribuido solo puede garantizar dos de las tres propiedades: o consistencia, o disponibilidad, pero no ambas.

Imagina dos nodos replicados que dejan de comunicarse (partición). Llega una escritura a uno de ellos. Ahora una lectura llega al otro nodo, que no tiene esa escritura. El sistema debe decidir:

• Devolver el dato viejo (mantiene la disponibilidad, sacrifica la consistencia).
• Rechazar la lectura o esperar (mantiene la consistencia, sacrifica la disponibilidad).

No hay tercera opción. Por eso CAP es una elección, no un buffet.

Mucha gente cree que puede elegir "CA" (consistencia y disponibilidad, renunciando a P). En un sistema realmente distribuido esto es una ilusión: las particiones de red ocurren (cables que se cortan, conmutadores que fallan, latencias extremas). No puedes garantizar que nunca habrá una partición.

Por tanto, en un sistema distribuido la P es obligatoria, y la elección real se reduce a:

• CP: ante una partición, priorizo la consistencia (puedo dejar de responder).
• AP: ante una partición, priorizo la disponibilidad (puedo devolver datos viejos).

Un sistema "CA" solo tiene sentido en una única máquina (una base de datos relacional clásica en un solo servidor), donde no hay red que particionar.

La decisión depende del caso de negocio:

La pregunta guía siempre es: ¿qué es peor para mi negocio, dar una respuesta incorrecta o no dar respuesta?

CAP solo habla de qué pasa durante una partición, que es algo poco frecuente. PACELC, formulado por Daniel Abadi, completa el cuadro añadiendo qué pasa el resto del tiempo:

Partition: Availability o Consistency; Else (en operación normal): Latency o Consistency.

En otras palabras:

• Si hay Partición → eliges entre A y C (como en CAP).
• Si no la hay (Else) → aun así eliges entre Latencia y Consistencia, porque garantizar consistencia fuerte entre réplicas exige coordinación, que cuesta tiempo.

PACELC es más útil que CAP en el día a día, porque la mayor parte del tiempo no hay particiones, y aun así pagas un precio por la consistencia.

La consistencia eventual no significa "datos incorrectos para siempre", sino que, si dejan de llegar escrituras, todas las réplicas acaban coincidiendo. Existen niveles intermedios útiles, como read-your-own-writes (un usuario siempre ve sus propios cambios).

Lo interesante de sistemas como Cassandra es que ajustas la consistencia por operación: escrituras críticas con QUORUM, lecturas tolerantes con ONE. Si lecturas y escrituras suman más réplicas que el total (W + R > N), obtienes consistencia fuerte sobre un sistema base AP.

Una clasificación orientativa (muchas son configurables y pueden moverse de categoría):

Toma esta tabla como guía, no como dogma: la configuración concreta (factores de replicación, niveles de consistencia) determina el comportamiento real.

• Confundir la C de CAP con la C de ACID: en CAP es "todas las réplicas coinciden"; en ACID es "integridad transaccional". No son lo mismo.
• Creer que puedes elegir CA en un sistema distribuido: las particiones ocurren; debes elegir entre CP y AP.
• Aplicar consistencia fuerte a todo: encarece latencia y reduce disponibilidad sin necesidad. Reserva la fuerte para datos críticos.
• Ignorar PACELC: el coste de la consistencia se paga también cuando NO hay particiones, en forma de latencia.
• Elegir base de datos por moda: elige según las garantías que tu caso de negocio necesita, no por la tecnología más sonada.

1. Enuncia el Teorema CAP y explica por qué, en un sistema distribuido real, la elección práctica se reduce a CP o AP.
2. Para cada caso, indica si elegirías consistencia fuerte (CP) o eventual (AP) y justifica: (a) saldo de una cuenta bancaria, (b) número de "me gusta" de una publicación, (c) reserva de una butaca en un cine.
3. Explica qué aporta PACELC frente a CAP y qué significa la clasificación "PA/EL".

1. CAP dice que, ante una partición de red, un sistema distribuido solo puede garantizar dos de las tres propiedades (C, A, P). Como las particiones son inevitables en un sistema realmente distribuido, P es obligatoria; por tanto, la elección real es entre CP (sacrificar disponibilidad para mantener consistencia) y AP (sacrificar consistencia para mantener disponibilidad).

2. (a) CP/fuerte: un saldo incorrecto es inaceptable; mejor un error que un dato erróneo. (b) AP/eventual: un desfase momentáneo en los "me gusta" es irrelevante; prima responder siempre. (c) CP/fuerte: no podemos vender la misma butaca dos veces, así que la consistencia manda.

3. PACELC añade qué ocurre cuando no hay partición: incluso entonces hay que elegir entre Latencia y Consistencia. "PA/EL" significa: ante una Partición prioriza la disponibilidad (A), y en operación normal (Else) prioriza la baja Latencia (a costa de consistencia). Es el perfil de sistemas como Cassandra.

Hemos aprendido que el Teorema CAP impone una concesión inevitable: ante una partición de red, hay que elegir entre consistencia (CP) y disponibilidad (AP). PACELC refina la idea recordando que, incluso sin particiones, pagamos en latencia por la consistencia. La elección entre consistencia fuerte y eventual, y la base de datos que la sustenta, deben responder siempre a las necesidades del negocio: ¿es peor una respuesta incorrecta o ninguna respuesta?

Con esta lección cerramos el Módulo 4, Arquitecturas Distribuidas y Microservicios. Has recorrido el camino completo: desde los fundamentos de los sistemas distribuidos y sus falacias, pasando por la descomposición en microservicios y bounded contexts, los mecanismos de comunicación, los patrones de resiliencia, hasta las concesiones de consistencia de datos. Estos conocimientos te permiten diseñar sistemas distribuidos robustos, conscientes de sus límites y adecuados a cada problema de negocio.