Foto de Brad Neathery na Unsplash
Vamos imaginar que uma pessoa está interessada em uma roupa para ir a uma festa. Ela procura em uma loja virtual e resolve efetuar a compra. Logo após escolher a cor e o tamanho, ela adiciona o produto no carrinho de compras, prossegue para o checkout e realiza o pagamento.
Após passar os dados para pagamento, a pessoa espera atentamente olhando para a tela do computador ansiosa para que o pagamento seja aprovado.
Para que essa jornada aconteça, vamos imaginar que temos quatro diferentes sistemas interagindo entre si:
Sistema de Pedidos: Responsável por receber o pedido, garantir que o produto esteja em estoque na cor e tamanho desejados e gerenciar o carrinho de compras;
Sistema de Pagamentos: Responsável por realizar o pagamento utilizando o cartão de crédito;
Sistema de Estoque: Responsável por gerenciar o estoque de todos os produtos;
Sistema de Logística: Responsável pela integração com a transportadora que vai realizar a entrega do pedido.
Cada um desses sistemas expõe uma API e o Sistema de Pedidos orquestra a jornada garantindo que cada etapa seja concluída com sucesso antes de mostrar a tela de sucesso.
Porém, como esses componentes dependem uns dos outros, o que pode acontecer se um deles estiver indisponível? Provavelmente a jornada vai ser comprometida e isso pode resultar em uma péssima experiência.
É aí que entra em cena o Princípio do Desacoplamento Temporal.
Princípio do Desacoplamento Temporal
Quando falamos em arquitetura de software, cada componente tem (ou deveria ter) sua responsabilidade bem definida. No entanto, existem ocasiões em que um componente precisa interagir com outro, seja para enviar ou receber dados/eventos ou mesmo solicitar um serviço. Nesse caso um “componente X” pode acabar tendo que aguardar uma resposta ou a disponibilidade de um “componente Y”, o que faz com que o primeiro fique ‘refém’ do segundo, o que chamamos de acoplamento.
Ao fazer chamadas síncronas entre serviços, estamos adicionando um acoplamento temporal. Isso significa que todos os serviços precisam estar disponíveis ao mesmo tempo para que tudo funcione corretamente.
Acoplamento é o grau de interdependência entre esses componentes e é contrastado com coesão. Baixo acoplamento é frequentemente considerado um sinal de um sistema bem desenhado e estruturado. Sempre existirá um certo grau de acoplamento, seja baixo ou alto. Onde colocamos a nossa régua é uma decisão a ser tomada considerando os diversos trade-offs que serão assumidos.
O Princípio de Desacoplamento Temporal diz que “um componente deve processar solicitações e eventos de forma assíncrona”.
O objetivo é romper a dependência de disponibilidade de tempo entre os componentes remotos. Em outras palavras, em vez de exigir que todos os componentes estejam disponíveis e acessíveis simultaneamente, permitimos que eles operem de forma mais independente e autônoma de forma assíncrona.
Trade-offs
Complexidade: Geralmente é mais complexo implementar um sistema com desacoplamento temporal pois é necessário implementar um sistema de eventos robusto, com gerenciamento de filas, mecanismos de persistência e tratamento de eventos fora de ordem.
Consistência eventual: Em vez de garantir a consistência imediata, o objetivo passa a ser buscar a consistência eventual. Isso significa que pode haver um período em que os eventos se propagam e os sistemas estejam em estados inconsistentes temporariamente.
Desafios de depuração e rastreamento: Quando ocorrem erros ou problemas em um sistema orientado a eventos, pode ser mais difícil rastrear e depurar as causas raiz. Os eventos podem viajar por várias partes do sistema, tornando a identificação e correção de problemas mais complexas.
Overhead de comunicação: A comunicação baseada em eventos pode resultar em um maior overhead de comunicação, especialmente em comparação com chamadas síncronas diretas entre componentes. Isso ocorre porque os eventos precisam ser publicados, consumidos e propagados pelos diferentes componentes do sistema.
Garantia de entrega: Garantir a entrega confiável de eventos em um sistema distribuído pode ser desafiador. É necessário implementar mecanismos de confirmação, repetição e recuperação de eventos para evitar perdas ou duplicação de eventos.
Conclusão
Embora ofereça benefícios, como escalabilidade e baixo acoplamento entre componentes, é necessário lidar com a complexidade adicional de implementar um sistema de eventos robusto e gerenciar a consistência eventual. Ao buscar aplicar o Princípio do Desacoplamento Temporal, adotando uma arquitetura orientada a eventos, é importante considerar esses desafios e encontrar soluções adequadas para garantir o bom funcionamento do sistema.
Quer saber mais?
Acesse estes artigos relacionados: