Dando continuidade às discussões sobre os 10 Desafios Simples de System Design, esse post é sobre Integração com Eventos via Webhook (parte 5/9).
Para ser capaz de resolver esse desafio, é importante primeiramente entender o que é uma Arquitetura Orientada a Eventos. Não é o objetivo desse material se aprofundar nesse assunto, mas – superficialmente falando – eventos são como notificações de coisas que ocorreram (um usuário cadastrado, um pagamento realizado, etc.). Um sistema/arquitetura sem eventos, geralmente é um sistema baseado apenas em comandos (cadastre um usuário, faça o pagamento, etc.). Comandos existem mesmo numa arquitetura orientada a eventos e são geralmente as fontes geradoras de eventos.
No mundo corporativo, geralmente webhooks são usados para integração/notificação de eventos entre sistemas de empresas diferentes localizados em redes diferentes. Isso ocorre porque webhooks nada mais são do que chamadas HTTP e HTTP é possivelmente o protocolo mais usado, conhecido, e interoperável que existe.
Sistemas corporativos que residem na mesma rede/da mesma empresa frequentemente usam middlewares específicos de mensageria como o Kafka, RabbitMQ, IBM MQ, etc. Dessa forma, outro ponto importante nesse desafio é entender que provavelmente haverá integração entre sistemas que residem em redes diferentes quando se usa webhooks.
A integração via eventos através de middlewares específicos de mensageria nos oferece muitas vantagens – mecanismos de tratamento de erros, retentativas, garantias de entrega, etc, são algumas delas. O material seguinte fala um pouco sobre isso.
Sendo assim, um dos principais desafios em uma integração via webhooks é o tratamento de erros. O que ocorre se o endpoint de callback estiver indisponível? Algumas integrações mais robustas com webhooks oferecem retentativas. Ou seja, se o endpoint não responder à requisição com um status code HTTP na faixa 200 haverá requisições posteriores. É de suma importância considerar esse aspecto de tratamento de indisponibilidade e erros.
Outro ponto importante é o tempo de resposta desejado para o endpoint do webhook. Talvez o endpoint de callback precise responder em um tempo máximo estipulado, caso contrário poderá ocorrer timeout da parte de quem fez a requisição (client timeout).
Bom, considerando a questão de tratamento de erros e tempos de resposta, uma abordagem comum para endpoints de callbacks é não realizar o processamento de forma síncrona durante o ciclo de vida da requisição, mas enviar os eventos recebidos para um processamento assíncrono, inclusive se apoiando em middlewares de mensageria já citados aqui. Dessa forma, a única operação de I/O durante o ciclo de vida da requisição seria enviar o evento para outro componente para processamento posterior (banco de dados, fila, etc.).
A segurança é um aspecto fundamental para esse problema. Considere sobre o endpoint de callback estar em uma rede pública ou conexão privada entre redes diferentes, tokens de acesso, revogação de tokens, VPNs, mTLS, regras de firewall com ranges de IPs de empresas, etc.
O desafio proposto direciona para a elaboração do endpoint que receberá os eventos, mas elaborar uma solução do ponto de vista de quem notifica os eventos (realiza os callbacks) pode ser bem interessante também. Por exemplo, como será feita a retentativa, qual intervalo entre elas, etc.
O material seguinte aborda sobre questões de retentativas.
Bom, é isso o que tinha para falar sobre integração via webhooks. Com certeza há muito mais aspectos do que os abordados aqui, mas espero que esse conteúdo tenha lhe dado uma boa intuição sobre os desafios da integração via webhooks.
Latest comments (1)
Boaaa mestre