Ir al contenido principal

Disponibilidad: Patron Retry

40 Patrones / 8 Categorías

Patrones Cloud
  • Disponiblidad
  • Administración de datos
  • Diseño e implementación
  • Mensajería
  • Administración y supervisión
  • Rendimiento y escalabilidad
  • Resistencia
  • Seguridad

  1. Disponibilidad
        Obviamente importante por que debemos ofrecer que si un usuario ingresa la aplicación debe estar accesible, prácticamente si la aplicación no esta disponible ningún otro atributo se usaría.

Retry Pattern
Patron de estabilidad y tal y como indica su nombre, consiste en reintentar una operación que ha fallado.

    Problema:


Usuarios usan aplicación 1 y está necesita comunicarse con la aplicación x.


Caso: Un usuario usa la aplicación 1 y está al consumir la aplicación x. Falla (time out, sobrecargado, conectividad,etc)


Que sucederia? La aplicación 1, fallaría y el usuario no sabe que está fallando la aplicación x


Solución

Usuarios usan aplicación 1 y está necesita comunicarse con la aplicación x.


Caso: Un usuario usa la aplicación 1 y está al consumir la aplicación xFalla por problema de red.

Qué hacemos? Re-intentamos

Vuelve a fallar

Qué hacemos? Re-intentamos

Y finalmente, dejar de fallar, y retornamos el resultado al usuario



El usuario recibe su respuesta, considerando que el tiempo de tardo no fue muy agradable. Pero finalmente la experiencia del usuario es positiva, "tardo en responder, pero fue exitosa"


Consideraciones

  • Reintentos en errores transitorios: debemos entender que errores se pueden generar momentáneamente, no se debe realizar un try sobre cualquier error. de lo contrario arrojar una excepción en otro tipo. (Ej: Disco Lleno)
  • Diseño de reintentos acordes a la app: Debemos conocer nuestra aplicación y la aplicación que vamos a consumir. No es lo mismo esperar 10 min en una aplicacion Batch a esa espera en una aplicación web.
  • Conocer donde hacer el retry: No hacer retry a aplicaciones que también hacen retry. 
  • Cancelar: Si el error indica que no nos encontramos ante un fallo temporal la operación debería ser cancelada y el error reportado o gestionado de manera adecuada.
Cuando usarlo?
  • Conocemos la api sobre la que vamos a hacer retry
  • Es posible el éxito luego de n intentos   
  • Siempre que la aplicación lo permita.




Figure 1 - Invoking an operation in a hosted service using the Retry pattern
     


   

Comentarios

Entradas más populares de este blog

Antipatrones Microservicios

1. Migración de Manejo de Datos Antipatron. El antipatrón de migración basado en datos se produce principalmente cuando se migra de una aplicación monolítica a una arquitectura de microservicios. La razón por la que esto es un antipatrón es que al principio parece una buena idea migrar la funcionalidad del servicio y los datos correspondientes al crear microservicios, pero como aprenderá en este capítulo, esto lo llevará por un mal camino que puede resultar en alto riesgo, exceso de costo y esfuerzo de migración adicional. Comprender los riesgos relacionados con la migración de datos y la importancia de "datos sobre funcionalidad" es el primer paso para evitar este antipatrón. La técnica para evitar este antipraton consiste en realizar primero una migración de la funcionalidad, es decir, primero refactorizar el código fuente, pasando por primero modularizar el contexto o dominio y continuar con la definición y construcción de servicios, a medida que se conoce el código que se...

Microservice Architecture | Arquitectura de microservicios

Qué es  Arquitectura de microservicios ?   El estilo arquitectónico de microservicios es un enfoque para desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP. El hecho de que los  servicios son implementables y escalables de manera independiente, cada servicio también permite que se escriban diferentes servicios en diferentes lenguajes de programación. También pueden ser gestionados por diferentes equipos. Las aplicaciones creadas a partir de microservicios pretenden ser lo más desacopladas y cohesivas posible: poseen su propia lógica de dominio y actúan más como ltros en el sentido clásico de que reciben una solicitud, aplican la lógica según corresponda y producen una respuesta. Un servicio es una funcionalidad que se expone para su uso por otros procesos .  Que otros protocolos puedo us...

Referencia | Material de Apoyo

Arquitectura .NET Architecture Guides Architectural Patterns: Uncover essential patterns in the most indispensable Domain Driven Design Quickly Microservicios Practical Microservices: By Umesh Ram Sharma Building Microservices: Designing Fine-Grained Systems By Sam Newman SOA Design Patterns By Thomas Erl