Hoje vamos falar um pouco sobre a resiliência.
Não é novidade falar sobre resiliência em nossas aplicações, já faz muito tempo que nós, profissionais de TI, buscamos maneiras de nossas aplicações se resolverem sozinhas, buscarem alternativas e serem “autônomas” não voltando a nos assombrar com falhas inesperadas.
Mas nos últimos anos esse conceito ficou ainda mais hypado, fazendo com que dediquemos ainda mais tempo nessa matéria, quando estamos desenvolvendo uma nova função sistêmica.
Quando falamos de resiliência, podemos pensar em várias “camadas” de ação.
Podemos pensar em resiliência dentro do seu microsserviço, com técnicas como a de circuit braker ou bulkhead, podemos pensar em resiliência na camada de infra, com decisões de subida de máquina para manter sua aplicação de pé, resiliência na camada de dados, dentre outras, mas nesse artigo vamos falar sobre resiliência na camada de arquitetura, ou seja, como os microsserviços se correlacionam para garantir a continuidade do negócio.
Bom, agora que afunilamos nosso escopo e “quebramos nossa história”, vamos aos fatos.
Quando ouvimos a palavra resiliência, pensamos logo em como manter tudo funcional, como fazemos com que nosso sistema esteja 100% todo o tempo, sem causar nenhum impacto ao usuário. E por vezes essa abordagem nos deixa cegos quanto as possibilidades.
Participei de algumas definições, onde buscávamos a resiliência de nossa aplicação, vi o time totalmente dedicado a não deixar a aplicação falhar, a deixar o usuário seguir, mas esse viés estava fazendo com que nós não entendêssemos que fazer o usuário seguir, as vezes passa por aceitar uma falha, ou minimizar a falha no processo anterior, para que o próximo possa seguir.
Bom, mas isso está muito abstrato, como assim um processo falhar, para deixar com que o próximo não falhe?
Bom, aqui vai um caso prático.
Imagine um sistema de compras de uma pequena empresa.
Nessa empresa, o setor de compras conta com quatro funcionários, que são responsáveis pela compra de equipamentos musicais. E um gerente responsável pela aprovação dos pedidos.
Essa empresa possui certo “convenio” com alguns fornecedores de corda de violão, deixando pré aprovado um valor determinado para cada marca.
Aqui vai aquele belo desenho para ilustrar, rs.
Nesse cenário, se pensarmos em um sistema todo feito com requisições, e chamadas síncronas, teremos a indisponibilidade da aplicação caso qualquer peça falhe, ou seja, se o efetivar compra estiver fora, você perde toda a sua compra, correndo o risco do seu cliente ir comprar no concorrente, ruim né?
Uma abordagem nesse cenário seria trabalhar postando em filas, de forma assíncrona, não dependendo de retorno da requisição para continuidade do processo.
Nesse cenário, a primeira chamada seria direta no serviço de listar convênio, que devolveria os convênios disponíveis, o segundo poderia ser uma fila para escolha de produtos e depois uma fila para efetivação da compra.
Aqui resolvemos um problema, caso a efetivação da compra esteja fora o pedido está na lista, e será processado assim que o microsserviço voltar. Mas caso o segundo comprador siga utilizando o mesmo convênio, você corre o risco de extrapolar o limite pré aprovado, podendo trazer um risco de crédito.
Bom, dado isso, vamos abandonar a ideia e seguir então com uma aplicação síncrona, que garanta nossa integridade financeira, e que não coloque o credito em risco. Essa seria a decisão mais fácil, mas aqui vai um desenho de uma solução alternativa, que não resolve o problema como um todo, mas diminui os impactos.
Nessa abordagem, o primeiro comprador listou os convênios e escolheu o convenio 1, com um limite de 1.000 reais. Escolheu os produtos e efetivou a compra, que ficou represada pois o microsserviço de efetivar compra estava quebrado. Esse cliente já seguiu com seu pedido efetivado e sem nem saber do ocorrido, que será resolvido assim que o microsserviço voltar.
Nessa abordagem, duas peças foram incluídas, uma de reserva de convênio e uma de liberação de reserva.
Ao enviar a efetivação do pedido, o microsserviço postou também uma reserva de convênio, bloqueando o convênio 1. Caso o microsserviço de efetivação estivesse disponível, o mesmo enviaria um pedido de liberação da reserva, fazendo o convenio 2 ficar disponível no mesmo instante.
No nosso cenário, o microsserviço de efetivação está fora, sendo assim o convenio 1 está comprometido, o que não impede o operador 2 de seguir com os demais convênios disponíveis, não travando todo o fluxo. Ou seja, liberamos a operação com menos funções, “Vão-se os anéis, ficam os dedos”.
Temos diversos tipos de abordagem para resolução desse problema, esse exemplo foi apenas um, para exercitar a reflexão proposta, ser resiliente, significa estar 100% o tempo todo?
Obrigado por ler até o fim, deixe seu comentário, conte sua experiência. Ajude a manter esse canal vivo.
Forte abraço, Natan Pasquarelli Freitas.
Deixe uma resposta