Resiliência em comunicação HTTP - Você está preparado para falhas?

Resiliência proativa em comunicação HTTP é algo crucial nos dias atuais em que estamos cercados de serviços, microserviços, integraçoes... A probabilidade de erros e fahas acontecerem é alta, sabemos que em algum momento algo irá acontecer, então precisamos estar preparados.

Abaixo listei algumas boas práticas que permitem que nossas aplicações lidem com falhas temporárias, sobrecargas e outros problemas de maneira eficiente, minimizando ao máximo o impacto na experiência de usuários, no caixa da empresa, e na confiabilidade que a empresa te perante seus consumidores (Sim, tudo isso está em jogo quando estamos falando de falhas em sistemas).

Retry

Objetivo: Repetir uma solicitação falhada após um intervalo de tempo definido.

Quando Usar: Utilize o padrão retry para lidar com falhas temporárias de rede ou serviços que podem ser recuperáveis em tentativas subsequentes.

Exemplo de Uso: Quando um serviço externo não está disponível temporariamente devido a uma falha de rede ou error transitório, a aplicação pode tentar novamente a solicitação após um breve intervalo.

Timeout

Objetivo: Definir um limite de tempo máximo para aguardar uma resposta a uma solicitação.

Quando Usar: Use o padrão timeout para evitar que a aplicação fique indefinidamente esperando por uma resposta de um serviço que está demorando muito para responder.

Exemplo de Uso: Configurar um tempo limite de 2 segundos para receber uma resposta de uma API externa. Se a resposta não for recebida dentro desse período, a solicitação é abortada.

Circuit Break

Objetivo: Prevenir falhas contínuas desativando temporariamente o acesso a um serviço que está apresentando problemas.

Quando Usar: Utilize o padrão circuit break quando um serviço externo está consistentemente falhando, para evitar sobrecarregar o serviço e degradar a performance do sistema.

Exemplo de Uso: Se um serviço falhar 5 vezes consecutivas, o circuito se abre e as solicitações futuras são bloqueadas por um tempo, permitindo que o serviço se recupere.

Concurrence Limiter

Objetivo: Limitar o número de solicitações simultâneas a um serviço.

Quando Usar: Use o padrão concurrence limiter para controlar a carga em um serviço, evitando sobrecarregar servidores ou componentes críticos.

Exemplo de Uso: Permitir no máximo 10 conexões simultâneas a serviço de terceiro para evitar a saturação do recurso, ou ser bloqueado por um limiter no terceiro.

(Outbound) Rate Limiter

Objetivo: Controlar a taxa de solicitações a um serviço em um determinado período.

Quando Usar: Utilize o padrão rate limiter para prevenir abusos e limitar o impacto de um grande volume de solicitações em curto espaço de tempo. Aqui estamos falando de limitar a saída das requests para um sistema de terceiro e não limitar entrada de requests em nosso sistema.

Exemplo de Uso: Limitar o número de requisições a uma API de terceiro a 100 por minuto para garantir a disponibilidade e desempenho do serviço, ou talvez evitar exceder uma quota contratada.

Hedging

Objetivo: Enviar múltiplas solicitações redundantes para diferentes instâncias de um serviço e usar a resposta que chegar primeiro.

Quando Usar: Use o padrão hedging para melhorar a latência e a confiabilidade das respostas, especialmente em ambientes onde a latência de rede pode ser variável.

Exemplo de Uso: Enviar solicitações simultâneas a dois servidores diferentes e utilizar a resposta que chegar primeiro, descartando a outra.

Conclusão

Esses padrões de resiliência ajudam a construir sistemas mais robustos e confiáveis, capazes de lidar com falhas e manter a qualidade do serviço oferecido aos usuários mesmo em cenários em que nossa dependências apresentem instabilidade, otimizando a experiências dos usuários de nossos sistemas.

Espero que agregue :)

Vídeo sobre o tema

Gravei um vídeo onde falo bastante sobre cada um destes e mostro na prática, com exemplos em .Net.

Vídeo:
https://www.youtube.com/watch?v=JrNgxXDZSCw

Abraços e bons estudos