Hey dev, nos ponemos serios, este tema es muy importante y más si estás en sistemas distribuídos como microservicios, así que arrancamos!

Cuando trabajas con sistemas distribuidos, como arquitecturas de microservicios, tarde o temprano te enfrentas a un dilema: ¿qué pasa si hay fallas en la red? ¿Deberías seguir respondiendo aunque los datos estén desactualizados? ¿O deberías esperar a tener datos correctos aunque eso haga que el sistema no responda?

Ahí es donde entra en juego el Teorema CAP.

Qué es CAP Theorem

El Teorema CAP, propuesto por Eric Brewer en el año 2000 y demostrado formalmente en 2002, es un principio clave en el diseño de sistemas distribuidos. Afirma que todo sistema distribuido puede cumplir como máximo dos de las siguientes tres propiedades al mismo tiempo:

• C de Consistency (Consistencia) plantea que todos los nodos ven los mismos datos al mismo tiempo, es decir que no hay lecutras "desactualizadas".
• A de Availability (Disponibilidad) es cuando el sistema responde siempre a las solicitudes incluso si algunos nodos fallan.
• P de Partition tolerance (Tolerancia a particiones) es cuando el sistema continúa operando incluso cuando hay fallos en la red o en la comunicación entre nodos.

Puedes ver a los nodos que menciono como cada uno de los microservicios de un sistema distribuído para que me entiendas mejor 😉

Qué significa esto en la práctica...

En presencia de una error de red o mejor dicho de una partición (fallos en la comunicación entre nodos, la letra P del CAP), no se puede tener al mismo tiempo consistencia y disponibilidad. Es decir:

• Si eliges Consistencia, podrías sacrificar Disponibilidad (el sistema se niega a responder hasta estar seguro).
• Si eliges Disponibilidad, podrías sacrificar Consistencia (el sistema responde, aunque los datos aún no estén sincronizados).

Como en los sistemas distribuidos las particiones son inevitables (por red, latencia o errores), el CAP theorem obliga a escoger entre "C" y "A" cuando ocurre una partición.

Ejemplo Real: Manejo de Productos en un Sistema E-Commerce hecho con Microservicios

Arquitectura base

Supongamos que estás desarrollando un e-commerce basado en microservicios. Tienes al menos dos servicios involucrados:

• Servicio de Catálogo de Productos (crea y actualiza productos).
• Servicio de Carrito de Compras (necesita mostrar información del producto al usuario).

En lugar de que el servicio del carrito consulte al catálogo directamente, decides desacoplarlos usando un sistema Pub/Sub (por ejemplo, con Kafka, RabbitMQ o Azure Service Bus).

Entonces cada vez que se crea o actualiza un producto, el servicio de catálogo publica un evento. El servicio de carrito consume ese evento y actualiza su propia copia local de los productos.

¿Qué papel juega CAP en este diseño?

🔥 Tolerancia a particiones (P)

Como los servicios están distribuidos y se comunican por red, es obligatorio tolerar fallos de red.

Entonces, bajo una partición, solo puedes elegir entre:

• Consistency (C): Garantizar que ambos servicios tengan siempre los mismos datos.
• Availability (A): Permitir que ambos servicios sigan funcionando incluso si están desincronizados.

✅ ¿Qué elegimos?

En este caso, elegimos disponibilidad (A) y tolerancia a particiones (P). Eso significa que:

• El servicio de carrito sigue funcionando incluso si aún no ha recibido el último evento de actualización del producto.
• A cambio, los datos pueden estar ligeramente desactualizados (ej. nombre, precio o stock antiguo).

Esto es lo que se conoce como consistencia eventual.

📈 Ventajas del enfoque A + P

• Mejora el rendimiento y escalabilidad.
• Desacopla los servicios.
• Evita bloqueos si un servicio está temporalmente caído.
• Permite reintentos y procesamiento asíncrono.

⚠️ ¿Cuándo no aplicar este enfoque?

Si el sistema requiere consistencia fuerte, por ejemplo:

• Procesamiento de pagos.
• Ajuste en tiempo real del inventario.
• Validación de stock antes de confirmar la compra.

En esos casos, podrías tener que sacrificar disponibilidad y aplicar patrones más complejos como SAGA.

En un sistema distribuido, si hay fallos de red, debes decidir entre responder rápido o responder con datos actualizados. El CAP Theorem te obliga a elegir.

Así que estimado dev, ya sabes, el Teorema CAP no es solo una teoría académica: es un principio que condiciona el diseño real de tu arquitectura distribuida. En nuestro ejemplo del e-commerce, optar por Pub/Sub y consistencia eventual es una decisión válida cuando lo más importante es mantener el sistema disponible y tolerante a errores, incluso si eso implica cierto desfase de datos.

Y si esta entrada te ha gustado, como supongo que es el caso 🔥😉 compártela!

Créditos de imagen de portada: Basado en Foto de anvesh baru en Unsplash