Transacciones distribuidas: ¿Saga o 2PC?

El desafío de la consistencia en sistemas distribuidos

Cuando dividimos una aplicación monolítica en múltiples microservicios, cada componente pasa a tener su propia base de datos aislada. En la práctica, esto significa que una operación simple, como procesar una compra de comercio electrónico, ahora requiere guardar datos en diferentes servicios: inventario, pago y facturación. Si el servicio de pago falla después de que el inventario ya se redujo, el sistema debe revertir el proceso. Mantener la integridad de los datos sin paralizar todo el ecosistema es el gran dilema de la ingeniería moderna, obligando a los equipos a elegir entre el rigor del bloqueo total y la flexibilidad de la consistencia eventual, tal como ocurre cuando desacoplamos bases de datos en microservicios heredados.

Cómo funciona el commit de dos fases en la práctica

El protocolo de confirmación de dos fases, conocido como 2PC, intenta garantizar que una transacción a través de múltiples bases de datos ocurra de forma atómica, es decir, o todo se guarda o nada cambia. En la primera fase, llamada preparación, un coordinador pregunta a todas las bases de datos participantes si pueden almacenar los datos. Cada base de datos reserva sus registros y responde con un voto positivo o negativo. En la segunda fase, si todos votaron 'sí', el coordinador emite la orden de grabado definitivo; si alguien falla, todos deshacen la operación. En la práctica, esto se parece a un viaje de amigos que solo se confirma si absolutamente todos están de acuerdo.

Cuellos de botella invisibles y riesgos operativos del 2PC

A pesar de su rigidez en la garantía de consistencia, el 2PC tiene un talón de Aquiles insuperable en sistemas de alto volumen: el bloqueo de recursos. Mientras las bases de datos esperan la respuesta del coordinador en la primera fase, las filas afectadas de las tablas quedan bloqueadas para otras peticiones. Si la red oscila o un nodo tarda en responder, las conexiones se acumulan y el rendimiento de la base de datos se desploma. En entornos de nube modernos donde los fallos transitorios de red son comunes, depender de bloqueos síncronos convierte al 2PC en un generador de cuellos de botella, un problema recurrente que los equipos intentan mitigar cuando analizan la lentitud con trazabilidad distribuida.

La alternativa del patrón Saga y la consistencia eventual

Para escapar de la trampa del bloqueo de recursos, la arquitectura moderna adoptó el patrón Saga. En lugar de una transacción única y bloqueante, la Saga divide el flujo en una secuencia de transacciones locales independientes ejecutadas en cada microservidor. Cada paso actualiza su propia base de datos y emite un evento informando que el trabajo concluyó. En la práctica, esto funciona como una línea de ensamblaje industrial: cada estación hace su parte y pasa el producto al siguiente. Si algo sale mal en el tercer paso, el sistema no deshace la transacción bloqueando la base de datos, sino que ejecuta acciones compensatorias específicas para anular el efecto de los pasos anteriores, aceptando que el sistema alcance el estado correcto de forma eventual.

Para coordinar esta secuencia de pasos sin perder el control del flujo, los ingenieros suelen elegir entre dos enfoques principales: la coreografía y la orquestación. En la coreografia, los microservicios se comunican entre sí mediante buses de mensajes de forma descentralizada, lo que funciona bien en flujos cortos pero puede generar dependencias difíciles de rastrear a medida que el sistema crece. En la orquestación, existe un componente centralizado —el orquestrador— que conoce todo el flujo de negocio, decide qué servicio llamar a continuación y dispara transacciones compensatorias automáticamente si ocurre algún error inesperado.

Comparando costos, resiliencia y complejidad operativa

Elegir entre Saga y 2PC no es una cuestión de blanco o negro, sino de aceptar los compromisos inherentes a su modelo de negocio. El 2PC garantiza consistencia inmediata sin exigir código complejo de reversión, pero sacrifica la disponibilidad y la escalabilidad bajo alta carga. Por otro lado, la Saga exige un esfuerzo significativo de desarrollo para diseñar transacciones compensatorias seguras y manejar estados intermedios inconsistentes, pero ofrece alta resiliencia y tolerancia a fallos. Si su sistema maneja transacciones financieras estrictas donde los centavos no pueden diferir ni por un segundo, el 2PC puede ser necesario; para casi todo lo demás en la web moderna, la Saga entrega la elasticidad requerida para el crecimiento sostenible. Para profundizar en estos conceptos arquitectónicos en producción, consulte también nuestro análisis técnico sobre Por qué la IA alucina y cómo crear barreras en LLMs.

Consideraciones finales sobre consistencia distribuida

Diseñar sistemas distribuidos exige abandonar la ilusión de que la red es totalmente confiable y que las bases de datos operan sin latencia. Comprender las limitaciones del 2PC y adoptar la complejidad controlada del patrón Saga es un rito de paso para los arquitectos de software que gestionan millones de peticiones diarias. Evalúe siempre el impacto comercial de una inconsistencia temporal antes de optar por bloquear toda su infraestructura en busca de una perfección síncrona inalcanzable.