Al diseñar la interacción entre microservicios, a menudo surge la cuestión de la implementación de transacciones distribuidas. En los monolitos, se dispone de mecanismos de control incorporados, pero en los microservicios la situación se complica debido a diferentes bases de datos, tecnologías y formatos de intercambio de datos. La regla principal es evitar transacciones distribuidas largas, ya que no se escalan bien y conllevan el riesgo de degradación del rendimiento.
En lugar de los clásicos protocolos ACID, se recomienda utilizar el patrón SAGA. Esta es una cadena de transacciones locales, donde cada microservicio registra sus cambios y, si es necesario realizar un retroceso, envía una operación compensatoria dentro de su responsabilidad.
Ejemplo de implementación simplificada de la gestión de la saga en Node.js con REST:
// Orquestador de Saga en Express app.post('/saga', async (req, res) => { try { await serviceA.transaction(); await serviceB.transaction(); res.send('ok'); } catch (err) { await serviceA.rollback(); res.status(500).send('se realizó la reversión'); } });
Características clave:
¿Se pueden usar los clásicos commits de dos fases (2PC) entre microservicios para soportar transacciones?
Sí, pero no se recomienda para arquitecturas de microservicios. 2PC ralentiza la escalabilidad y vincula los servicios tecnológicamente y organizativamente.
¿Son adecuados todos los escenarios de SAGA para operaciones financieras?
No. SAGA es más difícil de implementar correctamente para escenarios donde la rigidez ACID es crítica, por ejemplo, el cálculo de saldos en una cuenta. Aquí es importante evaluar los riesgos y elegir un compromiso.
¿Cómo se maneja el fallo de un paso intermedio, si el microservicio no puede revertir?
En tales casos, se debe implementar un protocolo de compensación manual o automatizado, posiblemente utilizando un registro de eventos separado.