Como DESENVOLVER software ROBUSTOS e de ALTO VALOR com POLÍTICAS DE RESILIÊNCIA
Introdução
Eu já estive no seu lugar.
Me lembro quando estava iniciando na tecnologia, sem muita noção, que atender regras de negócio era o ápice de um engenheiro. Eu achava aquilo mágico e até surreal.
Minha dificuldade, naquela era época, era atender regras de negócio. Mas, o que percebi ao longo do tempo é que essa dificuldade deve ser superada e que todo engenheiro deve conceber isso como o mínimo e, caso, você almeja CONQUISTAR uma CARREIRA de SUCESSO é necessário se atentar a conhecimentos profundos como esse.
É claro que o mínimo muitas vezes pode ser díficil, mas ter a humildade de compreender que não é só isso e que existe um mundo é extremamente importante.
Por isso, nesse post, irei falar um pouquinho do que foge desse "mínimo" e tentarei explorar um pouco o conceito de POLÍTICAS DE RESILIÊNCIA de modo a tanger conceitos como Circuit Breaker Pattern e Retry Pattern.
Sinta-se a vontade para engajar e me dar feedback's, estou aberto a sugestões, dicas e críticas.
Mas afinal, o que é resiliência?
Na vida como um todo, ser resiliente é ter a capacidade de se adequar e se posicionar perante a adversidades que percorrem o caminhar da sua vida a ponto de conseguir tomar decisões perante a conjuntura. De modo análogo a tecnologia, resiliência é a capacidade de um serviço, tecnologia, api ou sistema, resistir a falhas transitórias ou inesperadas de modo a se posicionar perante a elas a fim de tratá-las (como a utilização de um retry) e contorna-lás através de uma tomada de decisão (como a utilização de um circuit breaker).
Como adotar medidas de resiliência em suas tecnologias?
Agora que você já sabe o que é resiliência, como você pode adotar medidas de resiliência em suas tecnologias?
A primeiro momento, vale destacar, que há diversas medidas que corroboram para atingir tal objetivo, como Retry, Circuit Breaker, Timeout, Health Checks, Rate Limiting e em casos mais graves Disaster Recovery, entretanto, nessa postagem irem destacar o Retry Pattern e o Circuit Breaker Pattern.
Retry Pattern
Imagine que seu serviço tenha uma conexão com um banco de dados, querendo ou não, falhas transitórias de rede podem acontecer e quando digo falhas transitórias, são falhas transitórias mesmo, indisponibilidade por 5ms, 100ms, 200ms, ou até mais.
Você deixar de efetuar uma operação no banco de dados por falta de conexão provocada por falha transitória na rede, não é nada legal, reduz o aproveitamento de efetividade da requisição (SuccessRate), e além disso, pode causar transtornos na experiência do usuário final.
Dito isso, considere realizar retentativas da operação desejada no banco de dados, de modo a aplicar um delay entre cada operação de retentativa. Isso pode te ajudar!
Ahhhh... E um ponto que já iria esquecendo. Não faça uma implementação própria desse pattern, se for fazer, faça como estudo, mas geralmente, grande partes dos frameworks já possuem bibliotecas prontas que abrangem a resolução desses problemas técnicos que você vai vivenciar, de uma maneira intuitiva, transparente e facilitada.
Circuit Breaker Pattern
Imagine agora, que apesar de implementar o Retry Pattern, grande partes de suas operações no banco de dados persistem indisponíveis, agora, por longos períodos.
Você concorda que continuar retentando mesmo com indisponibilidade, pode sobrecarregar um serviço que está tentando se recuperar?
Se você concorda comigo, você entende que é necessário realizar uma tomada de decisão na sua tecnologia. Ela não pode continuar tentando fazer operações quando ela, observando o cenário de indisponibilidade pode tomar a decisão de não realizar a operação (haja visto que ela já sabe que está indisponível) e retornar uma operação tratada de volta, na qual corrobora para uma experiência do usuário adequada.
Lembrando quando falo de uma operação tratada pode variar desde mensagem de erro até um disparo de uma operação para ser executada tardiamente em uma fila de RabbitMq ou uma operação de contorno do problema.
Entretanto, isso é um papo que exige maiores aprofundamento e conhecimento da criticidade da operação perante as regras de negócios. Caso se sinta a vontade, você pode entrar em contato comigo através das minha redes sociais e lá trocamos uma ideia!