Patrones Cloud
- Disponiblidad
- Administración de datos
- Diseño e implementación
- Mensajería
- Administración y supervisión
- Rendimiento y escalabilidad
- Resistencia
- Seguridad
Patrón Compensating Transaction (Transacción de compensación)
Problema
Un usuario consumi nuestra Api, La Api realiza una serie de pasos
Crea un usuario (Puede hacerla ella misma o delegarla a otra Api o dejar un mensaje en una cola)
Ej: BD Sql Server
Alta en sistema externo (Dentro de la misma Api o delega a otro sistema)
Api Externa
Notifica al usuario (Notificación por socket)
Signal R
Notificación por mail (Mensajes a los usuarios y al admin)
SendGrid
Que ocurre si un paso falla?
Solución
Se debe tener un store centralizado, lo que va a guardar un estado y toda la información posible de todos los pasos. Se crea el usuario (Toda la información), Envia Email (A quien, hora, etc). Todos con el mismo ID.
El paso que falla notifica el evento y todos pasos realizan rollback o proceso de compensación (Eliminar Usuario, Dar de Baja al usuario, Una nueva notificación informando la tx errónea)
Todos los pasos deben ser autonomos e independientes (En lo posible en paralelo)
Consideraciones:
- Acciones de compensacion especificas por cada paso y para un problema en particular
- State Up Store debe esta siempre disponible (Dado su importancia).
- Acciones de compensación deben ser Idempotentes* , deben ser repetibles por que pueden fallar
- Guardar la máxima información de cada uno de los pasos
- No descartar que algún paso se deba compensar de manera manual.
- En ocasiones el rollback es demasiado complicado aun mas que la misma acción
Cuando usarlo?
- Sistema con pasos (No todos necesitan o soportan este patrón)
- Manejo consistencia eventual. Intentar evitar este patrón.
* la idempotencia es la propiedad para realizar una acción determinada varias veces y aun así conseguir el mismo resultado que se obtendría si se realizase una sola vez.
Patrones relacionados:
Información básica de coherencia de datos. El patrón Compensating Transaction se usa a menudo para deshacer operaciones que implementan el modelo de coherencia definitiva. En este manual se proporciona información sobre las ventajas e inconvenientes de la coherencia definitiva.
Patrón Scheduler-Agent-supervisor. Describe cómo implementar sistemas resistentes que realicen operaciones empresariales en las que se usen recursos y servicios distribuidos. En ocasiones, podría ser necesario deshacer el trabajo realizado por una operación mediante el uso de una transacción de compensación.
Patrón de reintento. Las transacciones de compensación pueden resultar costosas de realizar, y una forma de reducir su uso podría ser implementar una directiva efectiva de reintento de las operaciones con error siguiendo el patrón Retry.
Referencias:
Comentarios
Publicar un comentario