CAP y PACELC como ayudas para decidir, no como eslóganes

Qué es

CAP afirma que un sistema replicado no puede, mientras una partición de red separa sus réplicas, responder a todas las solicitudes en todos los lados y mantener a la vez cada lectura consistente con cada escritura. La retrospectiva de Brewer de 2012 (citada) sostiene que la formulación «2 de 3» era engañosa: CAP prohíbe solo una parte mínima del espacio de diseño, la disponibilidad y la consistencia perfectas en presencia de particiones, y, dado que las particiones son poco frecuentes, hay pocas razones para renunciar a una de las dos propiedades cuando la red funciona con normalidad. PACELC, de Abadi (citado), añade el caso que importa todos los días: si hay una partición (P), el sistema elige entre disponibilidad y consistencia (A o C); si no la hay (E, de else), en operación normal, elige entre latencia y consistencia (L o C). La crítica de Kleppmann (citada) repasa las ambigüedades de las definiciones de CAP y advierte de que interpretar CAP como prueba de que las bases de datos con consistencia eventual son «más disponibles» exige un razonamiento más cuidadoso.

Por qué importa

Las páginas de producto etiquetan los sistemas como «AP» o «CP» como si fuera una propiedad fija. Las preguntas útiles se plantean por operación: qué ocurre con una escritura en el lado minoritario de una partición, si un commit espera a las réplicas remotas y qué lecturas deben observar la última escritura. Un mismo almacén suele responder de forma distinta según la configuración (tamaños de quórum, replicación síncrona o asíncrona, nivel de consistencia por solicitud).

Cómo aplicarlo

• Enumera las operaciones que necesitan un invariante entre réplicas (nombres de usuario únicos, saldos que no pueden quedar en negativo, «leer tu propia escritura» tras enviar un formulario). Estas requieren coordinación; todo lo demás puede tolerar datos obsoletos durante un tiempo acotado.
• Para cada almacén, localiza el comportamiento documentado ante una partición (qué hace una minoría, si las escrituras se rechazan o se aceptan y se reconcilian después) y en operación normal (qué espera un commit).
• Registra la decisión en términos de PACELC en el registro de decisiones: «PA/EL para el feed de actividad, PC/EC para pagos».
• Diseña el modo de partición de forma explícita: cómo se detecta, qué operaciones se rechazan o se ponen en cola y cómo se reconcilia el estado después. El artículo de Brewer lo plantea como planificar la operación durante una partición y la recuperación posterior.
• Haz visible la obsolescencia de los datos: expón el retraso de las réplicas como métrica y fija un límite superior que el producto acepte.

Trampas

«CA» no es una opción para nada que use una red. La «consistencia» de CAP significa linealizabilidad, no la C de ACID. La «disponibilidad» en CAP se refiere a que todo nodo que no ha fallado responda, no a porcentajes de uptime. Una base de datos de un solo nodo con una réplica asíncrona ya se enfrenta a la elección de PACELC.