Minha experiência com a construção de Webhooks

Passei os últimos 5 anos estudando e criando microsserviços, com o tempo aprendi sobre como deixar essas aplicações resilientes, e com observabilidade, também aprendi como planejar e estruturar os projetos com as melhores práticas para atender milhões de requisições e se manterem estáveis e com a integridade dos dados alta, tudo isso sem prejudicar a experiência dos consumidores dos serviços.

Nesses anos de desenvolvimento, aconteceram muitos erros, muitos estudos, mais estudos e acertos, eu desenhei e fiz microsserviços para diversos fins, desde reconhecimento facial para check-in de companhias aéreas, que tinham milhares de requisições por mês, como para instituições financeiras com aplicações com milhões de requisições por mês.

Mas você deve estar se perguntando o que tudo isso tem haver com webhooks?

E eu me fiz essa mesma pergunta à alguns meses atrás, quando entrei para um projeto de bank as a services com a missão de criar uma plataforma onde alguns produtos do banco itaú e outros clientes externos poderiam se conectar e usar toda infraestrutura de aplicações e microsserviços em cloud que construimos para o iti, assim quem se conecta-se a essa plataforma poderia realizar as mais diversas tarefas como; Onboarding, criação de contas, timeline, transferências, pagamentos, gestão de pix e tantas outras funcionalidades que uma conta de banco tem e pode ter.

Mas como construir uma plataforma dessa magnitude de maneira efetiva, estável e que seja simples de se conectar? e como permitir a comunicação padronizada, segura e eficiente para um ou mais utilizadores que vão estar conectados a essa plataforma?

Como garantir a resiliência e integridade de todos esses dados para múltiplos utilizadores?

Estamos falando de algo que é por conceito exponencial, começamos com milhares de requisições por clientes, e vamos para milhões, em poucas rodadas de utilizadores novos se plugando à plataforma, dependendo exclusivamente da base de clientes do utilizador da plataforma, consegue perceber como isso é grande? ou melhor GIGANTE.

E foi nesse contexto que decidimos criar o primeiro webhook do bank as a service.

Webhook: o que é, como funcionam e quais suas vantagens?

Webhook é um conceito de recebimento de informações entre aplicações, que acontece a partir de o acionamento de eventos. Por definição os webhooks são assíncronos, ou seja, quando um evento ocorrer, o webhook recebe uma mensagem e ela será enviada em algum momento para o callback de destino, isso pode demorar 1 segundo, como 1 hora ou mais por exemplo.

Além disso, um webhook por definição é construído para ter alta disponibilidade e resiliência das informações retidas para fornecimento dos callbacks.

Por isso uma de suas maiores vantagens é fornecer uma padronização de mensagens para diversos tipos de consumidores, deixando assim flexível para cada utilizador criar seus meios de como tratar as mensagens recebidas, garantindo a eles segurança, disponibilidade e integridade dos dados que irão receber.

No BaaS (bank as a services) nós desenhamos e redesenhamos nosso webhook diversas vezes. Por ser um conceito, existem muitas formas de como aplica-lo na prática e ocorreram diversas conversas para decidir e refinar o padrão dos eventos, das mensagens, da segurança, do tipo de dado, autenticação e comunicação que iriamos trabalhar. E só então decidimos que precisávamos criar a primeira versão para um único utilizador (franquia) que entraria para ali poucos meses, então assumimos por deixar muitos débitos técnicos para quando fôssemos ser realmente multi utilizadores (multi-franquias).

Esse pensamento e jeito de trabalhar foi bem importante para testar as hipóteses e errar rápido, assim conseguimos corrigir e avançar mais rápido também.

Para se ter ideia, essa ambição de ter uma plataforma de bank as a services era algo recorrente no banco e que nunca tinha sido alçado por diversos motivos, mas nosso time conseguiu em pouco mais de 3 meses, e hoje em produção já temos mais de 1 milhão de contas abertas com nossa primeira franquia e todas sendo gerenciadas pelas aplicações que criamos no BaaS, com toda nossa robustez, a plataforma e o webhook se provaram nesse MVP.

Mas porquê conseguimos e os outros times não? Eu acredito que alguns fatores foram cruciais para isso ter acontecido:

1 - Cloud pública AWS, com ela conseguimos abstrair muitas burocracias que o banco tinha antes com a cloud privada. Como por exemplo pipeline de deploy automatizada, esteiras com validação de testes e cobertura de código, monitoração com aplicações reconhecidas no mercado e open source: kibana, jaegger, grafana, argoCD, harbor etc.

2 - Lugar certo na hora certa, acredito em construir o destino, em estudar e ficar preparado para quando oportunidades surgirem, e 2 anos antes de o BaaS nascer, estava nascendo o iti e o projeto marte, lá fundamos os alicerces e cultura que precisávamos para o BaaS conseguir existir hoje.

3 - Time de alta performance, por estarmos usando tecnologia de ponta, acredito que atraímos pessoas técnicas com alto nível de conhecimento e isso agregado a cultura que aprendi no iti, na equipe de DevX e que na fundação do BaaS muitos colegas de lá trouxeram essa cultura de inovação, colaboração e evangelização do aumentar a régua, e evoluir para contribuir como comunidade, fez toda a diferença na hora de entregar uma plataforma com robustez.

Com toda essa expertise, eu acredito que o maior aprendizado foi essa questão de assumir o risco e manter débitos técnicos para evolução.

Vou deixar aqui alguns aprendizados técnicos que tive nessa fase 1, onde assumimos que minimamente nosso webhook iria atender a apenas 1 franquia e que podem servir de insights para pessoas que estão pensando em criar webhooks em seu ecossistema.

Fase 1:

• Definir quais atributos da mensagem serão obrigatórios para todos tipos de eventos e ter um atributo coringa data, onde nele pode ser serializado informações adicionais para cada tipo de evento.
• Definir schemas e versões desses schemas para mensagens de sucesso e falha separadamente.
• Definir e alimentar uma base para auditoria dos dados que estão sendo trafegados nesse webhook.
• Criar mecanismos de exponencial backoff ( reter uma mensagem por um período de tempo caso algo falhe no envio da mensagem para um callback dos utilizadores )
• Criar mecanismos de reprocessamento dos eventos onde os clientes utilizadores da plataforma podem acessar em caso de falhas para fazerem reprocessamento sem precisar acionar nenhum time especifico seu, isso da autonomia para ambas as partes focarem em evolução da plataforma.
• A cereja do bolo é ter um portal para os desenvolvedores com toda documentação que um desenvolvedor vai precisar para conseguir se conectar à plataforma e receber as mensagens do webhook.
  Obs: Manter esse site atualizado e com as informações corretas é de suma importância, pois é dali que os devs que nunca tiveram contato com sua plataforma vão ter os insights necessários para criar e ter uma boa experiência criando suas aplicações de callback.
• Uma dica que faz toda diferença, é que nas primeiras rodadas de utilizadores da plataforma, vocês testem cada tipo de evento que está sendo enviado, e como os consumidores estão se comportando recebendo esses eventos, acredite, nessa etapa ambos vão encontrar possíveis erros que são importantes serem detectados o quanto antes.

Sobre a fase 1, acredito que é isso que gostaria de passar de insights para você leitor, espero que isso ajude no seu desenvolvimento e posso dizer que evoluímos muito o webhook desde então, estamos na reta final da fase 2, com muitas features novas, onde foram resolvidos todos débitos técnicos, realizadas muitas refatorações para o webhook começar a trabalhar com multi utilizadores (multi-franquias), e até mesmo a migração do dotnet core 3.1 para .net 5 com c# 9.0.

Como estou saindo do banco Itaú, não sei ainda como isso tudo irá continuar, mas provavelmente volto para contar tudo que aprendi e evolui nesse projeto na fase 2, é sobre isso clã, evoluir e estudar sempre 😍

Até a próxima e lembre-se sempre; Don’t stop learning!