Quando uma mensagem chega pelo WhatsApp, ela tem menos de 3 segundos para encontrar o caminho certo — ou o cliente já digitou "quero falar com um humano". Esse é o problema que resolvemos 30 milhões de vezes por mês. E o que aprendemos construindo essa máquina não está em nenhum whitepaper.
O problema que ninguém vê
A maioria das empresas pensa em WhatsApp como um canal simples: mensagem entra, operador responde. Na escala de 30 milhões de mensagens mensais, essa simplicidade é uma ilusão perigosa.
Considere os números: 30M de mensagens divididas por 30 dias dão 1 milhão por dia. Divididas por 10 horas de operação, são 100 mil por hora — ou 27 mensagens chegando a cada segundo. Agora multiplique isso por dezenas de tenants simultâneos, cada um com suas regras de roteamento, seus agentes de IA, suas filas de atendimento. O resultado é um sistema onde qualquer gargalo de 500 milissegundos se transforma em milhares de clientes esperando.
Na New Way, essa escala não é teórica. É o que processamos como BSP oficial da Meta, todos os dias. E a arquitetura que sustenta isso foi construída — e reconstruída — a partir de falhas reais.
Event-driven: por que não existe fila "principal"
A primeira decisão arquitetural que define tudo é: nenhuma mensagem espera em fila centralizada.
Nosso sistema é event-driven com sistema de filas assíncrono. Quando uma mensagem chega pelo webhook da Meta, ela dispara um evento que é consumido de forma assíncrona. Não existe um "servidor central" que processa tudo — existem mais de mais de 280 módulos especializados especializadas, cada uma responsável por uma fatia do processamento.
A vantagem? Se a função que classifica sentimento falha, a função que roteia para o operador continua funcionando. Se o módulo de IA está sobrecarregado, as mensagens de atendimento humano fluem normalmente. Isolamento de falhas não é um slide de apresentação — é o que impede que um bug no módulo de relatórios derrube o atendimento de 14 canais simultâneos.
O que aprendemos da forma difícil: triggers duplos no sistema podem causar dispatch duplicado de IA. Descobrimos isso quando um tenant recebeu respostas duplicadas em horário de pico. A solução envolveu constraints de unicidade e idempotência em cada ponto de entrada — não é elegante, mas funciona às 2h da manhã de uma segunda-feira.
Multi-tenant e isolamento de dados: cada cliente é uma fortaleza
Operamos em modelo multi-tenant com isolamento de dados por cliente nativo do banco de dados. Na prática, isso significa que o dado do tenant A é fisicamente invisível para o tenant B — não por lógica de aplicação que alguém pode esquecer de implementar, mas por política de banco de dados que o banco de dados enforce em cada query.
Parece óbvio, mas a maioria das plataformas SaaS no mercado de WhatsApp usa filtros de aplicação (WHERE tenant_id = X). Um desenvolvedor esquece o filtro em uma query, e dados vazam entre clientes. Com isolamento de dados, isso é impossível por construção.
O custo dessa segurança é complexidade. Cada migration precisa considerar as policies de isolamento de dados. Cada nova tabela precisa de grants corretos. Cada microsserviço especializado precisa do contexto de tenant. Mas quando você processa mensagens de operadoras de telecom, redes de varejo e multinacionais na mesma infraestrutura, não existe alternativa aceitável.
IA antes do humano: classificação em tempo real
Aqui está o dado que muda a conversa: entre 55% e 70% das interações são resolvidas por IA sem intervenção humana. Isso não acontece porque a IA é "inteligente" — acontece porque ela é rápida e classificatória.
Antes de qualquer mensagem chegar a um operador, ela passa por classificação automática: intenção, sentimento, urgência, histórico do contato. Essa classificação alimenta o roteamento inteligente (o que chamamos internamente de yaRoute), que decide em milissegundos se a conversa vai para IA, para um operador especializado, ou para uma fila prioritária.
O resultado prático: operadores humanos recebem apenas as conversas que realmente precisam de julgamento humano. Não perdem tempo com "qual o horário de funcionamento" ou "meu boleto não chegou". E quando recebem uma conversa, já têm contexto completo — histórico, sentimento detectado, tentativas anteriores de resolução.
Roteamento inteligente: o cérebro invisível
Receber 27 mensagens por segundo é metade do problema. A outra metade é decidir o que fazer com cada uma delas — em milissegundos.
O módulo de roteamento (yaRoute) funciona como um sistema de triagem de pronto-socorro. Cada conversa recebe uma pontuação composta: intenção (venda, suporte, informação), urgência (reclamação, elogio, pergunta casual), valor do cliente (novo, recorrente, VIP), e carga atual das filas. Com base nessa pontuação, a conversa é direcionada para o recurso mais adequado — que pode ser uma IA especializada, um operador humano de vendas, um operador de suporte técnico, ou uma fila prioritária.
O que torna isso complexo em multi-tenant é que cada empresa tem suas próprias regras. Para um ISP, "sem internet" é urgência máxima. Para um e-commerce, "rastreamento de pedido" é rotina. O mesmo tipo de mensagem tem prioridades completamente diferentes dependendo do tenant. O roteamento precisa ser configurável por empresa sem que a complexidade de um tenant afete a performance de outro.
Construímos isso com AI Zones dentro dos fluxos — pontos específicos onde a IA assume uma decisão determinística (classificar, rotear, qualificar) e devolve o controle. Não é um modelo monolítico tentando fazer tudo. São micro-decisões encadeadas, cada uma com seu próprio modelo e seus próprios critérios de fallback.
O resultado mensurável: operadores recebem conversas que correspondem à sua especialidade em mais de 90% dos casos. Isso reduz transferências internas (que frustraram o cliente e desperdiçam tempo de dois operadores) e aumenta a taxa de resolução no primeiro contato.
O que quebra em escala (e ninguém conta)
Três lições que não estão na documentação de nenhuma cloud:
Latência composta. Uma função que leva 200ms é rápida. Dez funções sequenciais de 200ms cada são 2 segundos — e o cliente já está impaciente. Aprendemos a paralelizar tudo que não tem dependência direta e a nunca fazer await em chamadas RPC no caminho crítico do processamento de mensagens.
Schema cache do API internaT. Depois de um deploy de migration, o API internaT mantém cache do schema antigo. Uma coluna nova que "não existe" para a API por 60 segundos causa erros intermitentes que parecem fantasmas. Hoje forçamos reload de cache em cada deploy — parece paranoia, mas eliminou uma classe inteira de bugs.
Deploy causa instabilidade. Cada deploy de microsserviços especializados gera 2 a 5 minutos de instabilidade enquanto as novas versões propagam. Por isso, nunca fazemos deploy em horário comercial. Toda atualização vai ao ar fora de pico, com monitoramento ativo.
O que fazer amanhã
- Audite seu modelo de isolamento de dados. Se sua plataforma usa filtros de aplicação em vez de isolamento de dados ou equivalente, você tem um vazamento de dados esperando para acontecer.
- Meça latência ponta a ponta, não por função. O tempo que importa é da chegada da mensagem até a resposta — não o benchmark de cada componente isolado.
- Classifique antes de rotear. Se toda mensagem vai para a mesma fila, você está desperdiçando o tempo dos seus melhores operadores com perguntas que uma IA resolve em 2 segundos.
- Faça deploy fora de pico. Parece básico, mas a maioria das equipes faz deploy quando o time está no escritório — que é exatamente quando os clientes estão conversando.