Azure Service Bus: Entendiendo el concepto de Transactions
Siguiendo el hilo de artículos sobre Azure Service Bus, esta vez quiero tocar un concepto o capacidad interesante que tiene Azure Service Bus: el concepto de “Transactions”.
Si aún no has leído el hilo sobre Azure Service Bus y asincronía, te dejo los enlaces de referencia sobre el tema:
Azure Service Bus: Entendiendo el Ciclo de Vida de un Mensaje
Arquitectura y Flujos Asíncronos en Azure: Alternativas y Criterios de Decisión
Azure Service Bus Transactions es un concepto que está ligado al principio ACID. Este principio busca que un conjunto de pasos sea Atómico, Consistente, Aislado y Durable. Es decir, las transacciones tienen que ser un conjunto de pasos que deben realizarse “todo o nada”. Si alguno de los pasos “falla”, se debe revertir toda la “transacción” y los pasos previos deben quedar sin efecto alguno. En el ecosistema de .NET y Azure, a este enfoque se le suele conocer como “Unit of Work” o unidad de trabajo.
Si bien, en términos teóricos, las transacciones de Azure Service Bus cumplen con el principio ACID, hay matices que debemos tener en cuenta al momento de la implementación, para saber qué cosas podemos o no podemos hacer:
- Con Transactions puedes manejar transacciones “locales”, esto quiere decir solo para manejos dentro de la misma instancia de Azure Service Bus. No está pensado para extenderse a otra instancia u otros servicios como SQL Database.
- Se pueden combinar operaciones de lectura y escritura de mensajes entre varias colas, tópicos y suscripciones, siempre y cuando pertenezcan a la misma instancia de Azure Service Bus.
- Transactions solo está disponible para niveles estándar y premium de Azure Service Bus, no se puede implementar transactions en el nivel Básico.
Pensemos ahora en un ejemplo de uso. Imaginemos una cola de “PedidosPendientes”, de la cual hay un suscriptor escuchando los mensajes. Cada vez que recibe un mensaje, realiza un proceso con dos pasos: enviar a la cola de facturación y al tópico de inventario, esto con el objetivo de que contabilidad lo facture y que se pueda actualizar el stock en inventario, respectivamente.
Si este pequeño ejemplo se implementa sin transacciones, podría fallar el envío a inventario; sin embargo, el envío a facturación sí se realizó. El problema está en que, como proceso de negocio, esta operación es inconsistente. Tal vez te preguntes: ¿Por qué podría fallar un simple envío entre colas? Este ejemplo se está simplificando bastante, pero en un escenario real, para realizar cada paso, ya sea inventario o facturación, vas a hacer pasos previos relacionados, por ejemplo, consumir una API externa o una fuente de datos, incluso cálculos complejos. Y sí, estos pasos previos podrían fallar y hacer que la operación quede inconsistente.
En un contexto de transacción, el receptor del pedido, además, debe iniciar la transacción y hacer una confirmación al finalizar cada uno de los pasos. Esto quiere decir que, así se haya enviado el mensaje a la cola de facturación y al tópico de inventario, mientras el receptor del pedido no confirme la transacción, estos mensajes no se harán visibles para los consumidores y suscriptores respectivos, garantizando así un enfoque ACID.
A continuación, un diagrama para representar este ejemplo:
Además, dejo un repositorio para este pequeño ejemplo, con .NET 9 y el SDK de Workers Service con TransactionScope:
Repositorio Ejemplo Azure Service Bus Transactions - Manejo de Pedidos
Conclusión
Azure Service Bus Transactions es un concepto interesante para implementar ACID en flujos asíncronos. Sin embargo, se debe tener claro el alcance y las limitaciones para una implementación correcta.
Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades