O Validation Service recebe eventos de entrada de diversos canais e garante que eles sejam válidos antes de encaminhá-los para os demais microserviços (atendimento, chatbot, CRM, analytics etc.).
Em plataformas omnichannel, milhares de mensagens chegam continuamente por diferentes canais como WhatsApp, Instagram, Facebook Messenger e Telegram.
Embora seja tentador realizar toda a lógica de negócio imediatamente após o recebimento do webhook, essa abordagem costuma gerar problemas de escalabilidade, disponibilidade e confiabilidade.
O Validation Service é um microserviço dedicado exclusivamente à validação da entrada de dados provenientes dos canais de comunicação.
Seu objetivo não é interpretar mensagens, responder usuários ou executar regras de negócio, mas garantir que tudo o que chega ao sistema seja legítimo antes de seguir para o restante da arquitetura.
Os eventos recebidos normalmente chegam através de webhooks de plataformas como:
Esse serviço atua como uma camada de segurança, impedindo que dados inválidos, adulterados ou provenientes de origens não autorizadas sejam propagados para outros microsserviços.
Após validar a autenticidade da requisição, a mensagem é publicada em uma fila para processamento assíncrono pelos serviços responsáveis por atendimento, chatbot, CRM, analytics e demais componentes da plataforma.
Sua responsabilidade termina exatamente nesse ponto.
O Validation Service possui responsabilidades bem definidas.
Ele deve:
Ele não deve:
Como o serviço recebe webhooks de provedores externos, ele expõe poucas rotas HTTP.
| Método | Endpoint | Finalidade |
|---|---|---|
| POST | /webhooks/meta | Recebimento de eventos da Meta |
| POST | /webhooks/telegram | Recebimento de eventos do Telegram |
| GET | /health | Verificação de saúde da aplicação |
| GET | /ready | Verificação de disponibilidade |
Por ser uma API exposta diretamente na Internet, toda requisição deve passar por validações de segurança.
Para eventos provenientes da Meta, é realizada a validação da assinatura HMAC enviada nos cabeçalhos da requisição.
Somente após confirmar que a assinatura corresponde ao payload recebido, a mensagem é considerada válida.
Essa validação impede alterações no conteúdo durante a transmissão e garante que o webhook realmente foi enviado pela Meta.
Para o Telegram, a autenticação ocorre através do Secret Token, configurado durante o registro do webhook.
Caso o token recebido não corresponda ao esperado, a requisição é imediatamente descartada.
Ao receber um webhook da Meta ou do Telegram, o objetivo da API não é processar toda a mensagem, mas apenas confirmar que ela foi recebida com sucesso.
Após validar sua autenticidade, a mensagem é publicada em uma fila e o serviço responde imediatamente com HTTP 200 OK.
Essa abordagem oferece diversas vantagens.
Se a plataforma de origem não receber um HTTP 200 dentro do tempo esperado, ela entende que a entrega falhou e realizará novas tentativas automaticamente.
Quanto maior o tempo de processamento, maior a quantidade de retransmissões.
Reenvios aumentam significativamente a chance de processamento duplicado.
Ao responder rapidamente, reduzimos naturalmente a necessidade de mecanismos complexos de idempotência.
Durante campanhas promocionais ou horários de maior movimento, milhares de mensagens podem chegar simultaneamente.
Responder rapidamente impede que conexões HTTP permaneçam abertas aguardando processamento interno.
Mesmo que um banco de dados ou outro microsserviço esteja lento ou indisponível, o recebimento dos webhooks continua funcionando normalmente, desde que a fila esteja operacional. Isso reduz significativamente o impacto de falhas internas.
Separar o recebimento do processamento permite escalar apenas os consumidores da fila conforme a demanda cresce. Não há necessidade de aumentar a camada responsável pelo recebimento dos webhooks sempre que houver maior volume de mensagens.
Meta / Telegram
│
▼
Validation Service
│
Validação HMAC / Secret
│
▼
RabbitMQ
│
▼
Consumidores
│
├── Atendimento
├── Chatbot
├── CRM
└── Analytics
Como exemplo, considere a seguinte infraestrutura hospedada na AWS.
| Componente | Configuração |
|---|---|
| Validation Service | AWS ECS Fargate |
| Tasks iniciais | 2 |
| Recursos por task | 0.5 vCPU / 1 GB RAM |
| RabbitMQ | 2 vCPU / 4 GB RAM |
| Auto Scaling | Baseado em CPU e Queue Depth |
| A seguir veremos como essa arquitetura se comporta em diferentes níveis de carga. |
Neste cenário, o volume de entrada é relativamente baixo e a infraestrutura opera com folga.
300 msg/s
│
▼
Validation Service
(2 Tasks ECS)
│
▼
RabbitMQ
│
▼
Consumidores
Fila ≈ 0 mensagens
Neste cenário não há necessidade de escalar a aplicação.
Com o aumento da carga, a fila começa a crescer temporariamente. O Auto Scaling identifica dois indicadores importantes:
Automaticamente o ECS aumenta o número de instâncias do Validation Service de 2 para 4 Tasks.
800 msg/s
│
▼
Validation Service
(4 Tasks ECS)
│
▼
RabbitMQ
│
▼
Consumidores
Fila
5.000
3.200
1.800
900
120
A fila funciona apenas como um buffer temporário até que os consumidores acompanhem novamente a velocidade de entrada.
Neste cenário ocorre um pico elevado de mensagens.
O Auto Scaling aumenta automaticamente o Validation Service para 8 Tasks, mantendo o recebimento dos webhooks estável. A partir desse ponto, o comportamento depende da velocidade dos consumidores.
Quando a taxa de consumo acompanha a taxa de publicação, o RabbitMQ permanece praticamente vazio.
Entrada
2.000 msg/s
│
▼
Validation Service
(8 Tasks)
│
▼
RabbitMQ
│
▼
Consumidores
2.000 msg/s
Fila
200
350
150
220
(quase sempre vazia)
Nesse cenário:
Agora considere consumidores processando apenas 500 mensagens por segundo.
Entrada
2.000 msg/s
│
▼
Validation Service
│
▼
RabbitMQ
│
▼
Consumidores
500 msg/s
Fila
10.000
↓
30.000
↓
80.000
↓
150.000 mensagens
Como a produção é maior que o consumo, a fila cresce continuamente. Consequentemente, o RabbitMQ passa a utilizar mais memória.
RAM
50%
↓
70%
↓
85%
↓
90%
Quando o limite configurado é atingido, o broker ativa automaticamente o mecanismo de proteção de memória.
Memory Alarm
↓
Paging
↓
Mensagens passam
a ser gravadas em disco
Mesmo durante o Paging:
Assim que houver memória disponível novamente:
Paging
↓
Desativado
↓
Mensagens voltam
para RAM
Esse mecanismo permite que o RabbitMQ absorva grandes picos de tráfego sem perda de mensagens.
O principal problema resolvido pelo Validation Service é a distribuição de trabalho (Work Queue). Cada mensagem precisa:
RabbitMQ foi projetado exatamente para esse tipo de cenário.
O Amazon SQS também atenderia ao problema.
Entretanto, algumas funcionalidades do RabbitMQ tornam sua utilização mais interessante nesse contexto.
No RabbitMQ é possível limitar exatamente quantas mensagens cada consumidor recebe simultaneamente.
prefetch = 20
Isso evita que uma instância fique sobrecarregada enquanto outras permanecem ociosas.
No SQS esse controle é mais limitado, sendo baseado na quantidade de mensagens buscadas por requisição (MaxNumberOfMessages).
RabbitMQ possui um mecanismo extremamente flexível baseado em Exchanges e Routing Keys.
instagram.*
↓
Fila Instagram
telegram.*
↓
Fila Telegram
No SQS normalmente seria necessário combinar SNS com múltiplas filas para obter comportamento semelhante.
RabbitMQ normalmente trabalha com latências de poucos milissegundos.
RabbitMQ
≈ poucos milissegundos
Enquanto isso, o SQS costuma apresentar latências maiores.
Amazon SQS
≈ dezenas de milissegundos
Embora essa diferença não seja determinante para webhooks, o RabbitMQ tende a responder mais rapidamente.
Outro diferencial importante é sua interface administrativa. Ela permite acompanhar facilmente:
Essa visibilidade facilita bastante a operação da plataforma.
Kafka resolve um problema diferente. Ele foi criado para plataformas de streaming de eventos, onde diversos consumidores precisam processar exatamente o mesmo evento.
Por exemplo:
Mensagem validada
↓
CRM
↓
Analytics
↓
Data Lake
↓
Machine Learning
↓
Chatbot
Nesse cenário Kafka é excelente. Entretanto, o Validation Service possui um fluxo muito mais simples.
Mensagem
↓
Validar
↓
Fim
Cada mensagem precisa ser processada apenas uma única vez por um único consumidor. Nesse contexto, Kafka adicionaria complexidade desnecessária.
Além disso, utilizar Kafka implicaria administrar diversos componentes adicionais:
Toda essa infraestrutura faz sentido para plataformas orientadas a eventos em larga escala, mas seria um excesso para uma fila dedicada exclusivamente à validação de webhooks.
O Validation Service atua como a primeira camada de defesa de uma plataforma omnichannel.
Ao concentrar exclusivamente a validação dos webhooks, responder rapidamente aos provedores e desacoplar o processamento através do RabbitMQ, a arquitetura ganha:
Esse padrão é amplamente utilizado em sistemas distribuídos de alta disponibilidade e representa uma abordagem simples, eficiente e robusta para lidar com grandes volumes de mensagens provenientes de múltiplos canais.