Construir uma plataforma de mensageria omnichannel vai muito além de simplesmente enviar e receber mensagens.
Construir uma plataforma de mensageria omnichannel vai muito além de simplesmente enviar e receber mensagens.
Quando uma empresa centraliza canais como WhatsApp, Facebook Messenger, Instagram, WebChat, Telegram, APIs proprietárias e brokers de mensageria em uma única solução, surgem desafios significativos relacionados a escalabilidade, disponibilidade, segurança e consistência dos dados.
Uma arquitetura bem planejada é fundamental para garantir uma boa experiência ao usuário final.
Além disso, ela deve ser capaz de suportar cenários adversos como:
Uma plataforma de mensageria precisa ser resiliente, escalável e observável para continuar operando mesmo quando parte da infraestrutura apresenta falhas.
Uma arquitetura moderna de mensageria omnichannel normalmente possui diversas camadas especializadas.
Conectores Externos
↓
Webhook
↓
Backend
↓
Fila
↓
Consumer
↓
Processor
↓
Workflow Engine
↓
Banco de Dados
Backend
↓
WebSocket
↓
Frontend
Cada camada possui responsabilidades específicas e desafios próprios.
Os webhooks representam a porta de entrada da plataforma.
É através deles que chegam mensagens provenientes dos diversos canais conectados.
Uma plataforma omnichannel pode receber eventos de:
Cada integração possui formatos e comportamentos diferentes.
A plataforma deve normalizar essas informações para um modelo interno único.
Grande parte dos provedores trabalha com timeouts agressivos.
Exemplo:
Webhook → Timeout de 5 segundos
Se o processamento completo ocorrer antes da resposta, há risco de:
Por isso o webhook deve:
Toda requisição recebida deve validar sua origem.
Exemplos:
Isso evita que agentes maliciosos enviem mensagens falsas para a plataforma.
Evitar respostas genéricas como:
500 Internal Server Error
Sempre que possível:
400 Bad Request
para payload inválido.
401 Unauthorized
para assinatura inválida.
403 Forbidden
para acesso não autorizado.
Isso facilita monitoramento e troubleshooting.
O backend é responsável por expor APIs utilizadas pelo frontend e coordenar operações da plataforma.
Mesmo durante grandes volumes de mensagens, o backend deve continuar disponível para:
Uma fila congestionada não deve tornar o sistema administrativo indisponível.
Toda comunicação deve utilizar:
Garantindo que cada usuário acesse apenas os dados autorizados.
Em caso de erro, o backend deve fornecer informações claras.
Exemplo:
{
"error": "validation_error",
"field": "phone",
"message": "Número inválido"
}
Permitindo que o frontend oriente corretamente o usuário.
O frontend é o ponto de contato entre a plataforma e seus operadores.
O sistema deve ser rápido e responsivo.
Mesmo empresas com milhares de atendimentos simultâneos precisam manter uma experiência fluida.
Em situações inesperadas o sistema deve informar claramente:
Exemplo:
Falha ao enviar mensagem.
Clique para tentar novamente.
O operador precisa saber:
Além do horário exato de cada evento.
O usuário não deve depender de:
F5
Atualizar página
Todas as atualizações devem ocorrer automaticamente através de WebSockets.
Os WebSockets são responsáveis pela comunicação em tempo real.
O sistema deve suportar:
Sem prejudicar a experiência do operador.
Nem todos os usuários devem receber todos os eventos.
Exemplo:
Mensagem Empresa A
Não pode chegar para:
Usuário Empresa B
O roteamento correto é essencial.
Cada evento deve validar:
Antes de ser distribuído.
O consumer processa mensagens recebidas das filas.
Ao consumir uma mensagem deve ser possível determinar:
Garantindo rastreabilidade.
Uma mensagem do WhatsApp de uma empresa nunca pode ser processada no contexto de outra empresa.
O isolamento entre tenants é obrigatório.
Mensagens problemáticas não podem bloquear a fila principal.
Fluxo recomendado:
Fila Principal
↓
Falha
↓
Dead Letter Queue
Se um provedor externo estiver indisponível:
Facebook indisponível
não deve impactar:
WhatsApp
Instagram
WebChat
O número de mensagens processadas simultaneamente deve respeitar os recursos disponíveis.
Exemplo:
CPU disponível
Memória disponível
Número de workers
Permitindo escalabilidade horizontal.
O processor é responsável pelo envio das mensagens para os canais externos.
Cada canal possui requisitos próprios.
Exemplo:
WhatsApp:
{
"to": "...",
"type": "text"
}
Facebook:
{
"recipient": "...",
"message": {}
}
O processor precisa transformar o modelo interno no formato esperado por cada provedor.
Cada empresa pode possuir:
Diferentes para cada integração.
Assim como o consumer, o processor deve:
Conforme o volume de mensagens.
A camada de workflows é responsável pelas automações da plataforma.
Exemplos:
O usuário espera respostas quase instantâneas.
Fluxos lentos prejudicam a experiência do atendimento.
Um erro comum é realizar múltiplas consultas ao banco em cada etapa do fluxo.
Isso gera:
Sempre que possível deve-se utilizar:
É fundamental registrar:
Permitindo auditoria e diagnóstico.
Ao executar integrações externas:
ERP
CRM
Gateway de Pagamento
API de Consulta
o workflow não deve bloquear toda a fila aguardando resposta.
Uma abordagem baseada em Promises e processamento assíncrono reduz gargalos.
Assim como consumers e processors, workflows devem permitir:
Conforme a demanda.