CAP con precisión

Pocas ideas de la informática han sido tan citadas y tan maltratadas como el teorema CAP. La versión que circula —consistencia, disponibilidad y tolerancia a particiones: elige dos— es pegadiza, cabe en una diapositiva y es engañosa en los tres términos a la vez: confunde lo que significa cada letra, presenta como elegible algo que no se elige, y sugiere una decisión permanente de arquitectura cuando lo que hay es una decisión momentánea que se toma mientras dura un fallo. Enunciado con precisión, el teorema dice algo mucho más modesto y mucho más útil, y ese enunciado exacto es la herramienta que necesitas para justificar por qué una aplicación local-first renuncia deliberadamente a garantías que otros sistemas consideran innegociables.

El enunciado tal y como se demuestra

La conjetura la formuló Eric Brewer en el año 2000 y la demostraron formalmente Seth Gilbert y Nancy Lynch en 2002. Su versión precisa exige fijar primero el modelo: una red asíncrona, sin relojes compartidos, en la que los nodos solo pueden razonar a partir de los mensajes que reciben. Sobre ese modelo se implementa un objeto simple, un registro de lectura y escritura replicado. Y entonces se definen las tres propiedades con un rigor que la versión popular pierde por completo.

Consistencia significa aquí exactamente linealizabilidad: debe existir un orden total de todas las operaciones tal que cada una parezca haber ocurrido de forma instantánea en un punto entre su invocación y su respuesta, y ese orden debe respetar el tiempo real. Si una escritura terminó antes de que empezara una lectura, la lectura tiene que verla. Disponibilidad significa que toda petición recibida por un nodo que no ha fallado debe terminar en una respuesta; no se exige que sea rápida, se exige que llegue. Tolerancia a particiones significa que el sistema debe seguir comportándose según su especificación aunque la red pierda un número arbitrario de mensajes entre nodos.

El teorema afirma que ninguna implementación satisface las tres. Y la demostración es tan corta que conviene tenerla entera en la cabeza, porque quien la recuerda deja de repetir la versión vulgarizada. Supón un sistema que las cumple las tres. Parte los nodos en dos grupos, G1 y G2, y haz que se pierda todo mensaje entre ellos. Un cliente escribe un valor nuevo en un nodo de G1; por disponibilidad, esa escritura tiene que completarse. Después, otro cliente lee de un nodo de G2; por disponibilidad, esa lectura tiene que responder algo. Pero G2 no ha recibido ninguna información sobre la escritura, así que devuelve el valor anterior. Existe entonces una lectura que empezó después de que terminara una escritura y que no la refleja: la historia no es linealizable. Contradicción.

// La demostracion entera, escrita como un guion de prueba.
particionar(G1, G2);            // se pierde todo mensaje entre los grupos

await escribir(G1.nodo, "v2");  // por disponibilidad, esta llamada TIENE que volver
const leido = await leer(G2.nodo);
// G2 no ha recibido nada sobre la escritura, asi que solo puede devolver "v1".
// Pero la lectura empezo despues de que la escritura terminara:
// no existe orden total compatible con el tiempo real. No es linealizable.
assert(leido === "v1");         // disponible y no consistente
// La unica alternativa era que G2 no respondiera: consistente y no disponible.

Hay una elegancia en la minimalidad del planteamiento que conviene apreciar, porque es lo que le da su fuerza. El objeto sobre el que se razona es lo más pobre imaginable: un registro con leer y escribir, dos clientes, dos grupos de nodos. Si la imposibilidad ya aparece ahí, aparecerá en cualquier sistema más rico, porque cualquier sistema más rico puede simular ese registro. Los resultados de imposibilidad se demuestran siempre así, sobre el caso más pequeño posible, y por eso resisten cualquier objeción del tipo pero mi base de datos hace cosas más listas: hacer cosas más listas nunca elimina una imposibilidad, como mucho la disimula en los casos frecuentes.

Fíjate en lo que la demostración no dice, que es tanto como lo que dice. No habla de rendimiento, ni de porcentajes, ni de bases de datos, ni de arquitecturas. Es un resultado de imposibilidad sobre un registro con dos operaciones. Toda la riqueza —y toda la confusión— aparece cuando se intenta aplicarlo a sistemas reales que no son registros y a garantías que no son linealizabilidad.

Los cuatro errores de la versión popular

El primero es el más grave y el que más arquitecturas ha estropeado. Un sistema descrito como CA no es un sistema que haya cambiado consistencia por disponibilidad renunciando a las particiones: es un sistema que se comportará mal cuando ocurra una partición, porque nadie decidió de antemano qué debía hacer. En cuanto la red pierda mensajes, ese sistema perderá C o perderá A igual que todos los demás. La única diferencia es que lo hará sin diseño, en el peor momento y con un comportamiento que nadie especificó.

El daño práctico de ese primer error es fácil de reconocer en el trabajo real: aparece cada vez que un equipo elige una pieza de infraestructura por su letra en lugar de por su comportamiento documentado bajo fallo. La pregunta útil ante cualquier componente nunca es qué dos letras dice tener, sino tres cuestiones concretas y verificables: qué ocurre exactamente con una escritura aceptada en el lado minoritario de una partición, si el sistema puede volver a servir un valor anterior a otro ya servido, y qué hace al reunificarse cuando los dos lados aceptaron cambios sobre el mismo dato. Un producto serio responde a las tres en su documentación; si no las responde, la letra que se atribuya no significa nada.

El segundo error explica por qué la etiqueta AP o CP dice tan poco de un sistema real. La disponibilidad de CAP es absoluta: toda petición a cualquier nodo no caído debe responderse. Bajo esa definición un sistema de quórum no es disponible, porque la minoría aislada rechaza peticiones, y sin embargo lo llamamos altamente disponible sin que nadie proteste. A la inversa, muchos sistemas etiquetados AP entregan garantías bastante más fuertes que la mera consistencia eventual. Las etiquetas son un titular, no una especificación.

El tercero es puramente terminológico y aun así hace estragos, porque la palabra consistencia se usa en la industria para al menos tres cosas incompatibles. En CAP significa linealizabilidad, una propiedad sobre el orden observable de las operaciones. En ACID significa que una transacción lleva la base de datos de un estado que cumple las restricciones declaradas a otro que también las cumple, lo cual no tiene nada que ver con réplicas ni con tiempo. Y en el habla cotidiana significa los datos están bien. Un sistema puede violar la C de CAP a plena luz y ser impecable en las otras dos acepciones; de hecho, esa es la descripción exacta de una aplicación local-first bien construida. Cuando alguien afirma que un sistema sacrifica la consistencia, la primera pregunta debe ser cuál de las tres.

El cuarto merece una precisión que ordena el resto del track. La disyuntiva no se aplica al producto entero sino a cada invariante. El cuerpo de un documento puede aceptar escrituras durante una partición sin ningún problema; el saldo de una cuenta no; la unicidad de un nombre de usuario tampoco. Un diseño maduro no elige una letra para toda la aplicación, elige una por cada clase de dato y asume que convivirán.

La elección real ocurre durante la partición

Puesta en estos términos, la pregunta útil deja de ser qué dos letras eliges y pasa a ser una pregunta operativa con tres tiempos. Brewer la reformuló así en su revisión del teorema doce años después, y esta formulación es infinitamente más productiva que la del titular.

flowchart LR
N[modo normal] --> D[se sospecha una particion]
D --> M[modo de particion]
M --> L[limitar que operaciones se aceptan]
M --> R[registrar intenciones para el futuro]
L --> V[vuelve la conectividad]
R --> V
V --> F[fusionar estados divergentes]
F --> C[compensar lo que no se pudo evitar]
C --> N
style M fill:#f38ba8,color:#11111b
style F fill:#cba6f7,color:#11111b
style C fill:#fab387,color:#11111b

Esta lectura tiene una virtud que la formulación popular no tiene en absoluto: es accionable. De elige dos de tres no se deduce ninguna tarea concreta. De este ciclo se deducen cuatro, y las cuatro se pueden asignar, estimar y probar.

El primer tiempo es detectar, y la lección anterior ya te dejó sin ilusiones al respecto: detectar es apostar. Lo que sí puedes hacer es que la apuesta sea explícita y que el sistema sepa en qué modalidad cree estar. El segundo tiempo es decidir qué se permite mientras tanto, y aquí es donde la granularidad rinde: editar texto, sí; crear una entidad con identificador local, sí; consumir una plaza de un aforo limitado, probablemente no, o sí pero registrándolo como intención revocable en lugar de como hecho consumado.

La distinción entre hecho consumado e intención revocable es la que hace que esta modalidad sea aprovechable y no un simple modo degradado. Registrar una intención cuesta lo mismo que registrar un hecho —una escritura local— pero cambia por completo lo que la interfaz puede prometer y lo que la recuperación puede hacer sin traicionar a nadie.

async function ejecutar(operacion) {
  if (modo === "particion" && operacion.requiereInvariantesGlobales) {
    // No la rechazamos: la registramos como intencion, que es revocable.
    await registrarIntencion(operacion);
    return { estado: "pendiente", revocable: true };
  }
  // Lo que converge por diseno se aplica igual en los dos modos.
  await aplicarLocalmente(operacion);
  return { estado: "aplicada", revocable: false };
}

El tercer tiempo es el que casi nadie diseña y el que más importa: la recuperación. Cuando la conectividad vuelve, hay que fusionar estados que divergieron y, en los casos en los que se rompió un invariante que no podía romperse, compensar. Y compensar no siempre es una operación técnica. Si dos réplicas particionadas vendieron la última entrada, ninguna estructura de datos va a inventar un asiento; lo que hay es un reembolso, una disculpa y una política de negocio. Aceptar que existe esa categoría de problemas, en lugar de fingir que un algoritmo la absorbe, es parte del rigor de este nivel.

Vale la pena notar que la compensación no es una derrota ni un parche: es un mecanismo perfectamente respetable, y el mundo lleva siglos funcionando así. Las aerolíneas sobrevenden con conocimiento de causa y compensan al pasajero que se queda fuera porque el coste esperado de la compensación es menor que el de coordinar. Los cajeros automáticos siguen entregando efectivo cuando pierden la conexión con el banco, limitando el importe para acotar el daño. Lo que estos ejemplos enseñan es que la elección entre coordinar y compensar es económica antes que técnica, y que se decide comparando el coste de la latencia y la indisponibilidad con el coste esperado de reparar los casos raros.

PACELC: el coste que sigue ahí sin partición

Queda un hueco que CAP no cubre y que resulta ser el decisivo para local-first. El teorema solo habla de lo que ocurre durante una partición, pero las particiones son minoritarias en el tiempo: la mayor parte de la vida del sistema transcurre con la red funcionando. Y en ese régimen normal la coordinación sigue costando algo, porque garantizar linealizabilidad exige hablar con otros antes de responder, y hablar con otros cuesta al menos un viaje de ida y vuelta.

Este hueco no es una omisión descuidada del teorema, sino una consecuencia de su enunciado: CAP habla de lo que es posible, no de lo que es rápido. Un sistema que tardase una hora en responder cada lectura seguiría siendo disponible según la definición formal, porque disponible significa que la respuesta llega, no que llegue a tiempo. Esa laxitud es imprescindible para que la demostración funcione en un modelo sin relojes, y a la vez es lo que hace que el teorema, por sí solo, no sirva para decidir arquitecturas de producto.

Daniel Abadi formalizó esa extensión con el acrónimo PACELC, que se lee como una frase con dos condicionales: si hay partición (P), elige entre disponibilidad (A) y consistencia (C); si no la hay (E, de else), elige entre latencia (L) y consistencia (C). La segunda mitad es la que explica por qué existe este track. Una aplicación local-first no adopta su arquitectura solo para sobrevivir al metro: la adopta porque incluso con red perfecta, preguntar antes de actuar impone un suelo de latencia que ninguna optimización elimina, y ese suelo es precisamente lo que arruina la sensación de que el documento es tuyo.

Esta segunda mitad tiene además la virtud de discriminar entre sistemas que CAP mete en el mismo saco. Dos bases de datos pueden coincidir en preferir la disponibilidad bajo partición y diferir por completo en lo que hacen el resto del tiempo: una replica de forma síncrona a varias regiones y paga ese viaje en cada escritura, la otra confirma en local y propaga después. Ambas serían AP en la clasificación popular y la diferencia entre ellas —decenas o centenas de milisegundos en cada operación— es la que decide si tu producto puede existir. La letra que de verdad importa es la que CAP no tiene.

Dicho en la nomenclatura completa, una aplicación local-first canónica es PA/EL: bajo partición prefiere seguir aceptando escrituras, y sin partición prefiere responder de inmediato desde la réplica local. Esa doble elección no se toma por gusto ni por moda técnica; se toma porque el producto que se quiere construir tiene la respuesta instantánea como requisito, y esa exigencia se propaga hacia abajo hasta obligar a renunciar a la linealizabilidad. La arquitectura no precede al requisito: se deduce de él.