comunicação em canal único apresenta um único ponto de falha. O WhatsApp pode ficar indisponível, um utilizador pode estar inacessível via RCS, uma rota da operadora pode apresentar problemas, um modelo pode ser rejeitado no meio de uma campanha. Uma estratégia de failover multicanal considera "entregar esta mensagem a esta pessoa" como o objetivo e o canal como um meio intercambiável. Veja como projetar uma estratégia que realmente funcione.
Defina a hierarquia de canais por tipo de mensagem.
Não existe uma ordem universal — a sequência correta depende da mensagem. Algumas recomendações padrão sensatas: para autenticação, WhatsApp ou RCS primeiro (com recursos avançados, personalização da marca e velocidade), depois SMS e, por último, OTP por voz. Para notificações transacionais, RCS ou WhatsApp primeiro para uma experiência personalizada, com SMS como alternativa garantida. Para alertas urgentes, priorize o SMS pela sua ampla disponibilidade e adicione a voz como medida de segurança. Defina a sequência de forma criteriosa, para cada tipo de mensagem, e anote-a.
O failover deve ser condicional, não cego.
- Falha de capacidade — o utilizador não está acessível no canal (nenhum RCS aprovisionado, nenhuma conta do WhatsApp). Encerre a conexão imediatamente; não espere.
- Falha na entrega — o canal aceitou a mensagem, mas o DLR mostra que ela não foi entregue. A entrega será processada com um recibo negativo.
- Falha de tempo limite — nenhum relatório de entrega positivo dentro de um prazo específico para o tipo de mensagem (curto para OTP, mais flexível para notificações). A mensagem é interrompida quando o tempo limite expira.
- Falha do fornecedor — o próprio canal está inativo. Detete por meio da monitorização da taxa de erros e redirecione todo o canal para todo o tráfego, não mensagem por mensagem.
Cuidado com entregas duplicadas
O bug sutil em todos os sistemas de failover é o envio da mensagem duas vezes — uma vez no canal que estava lento, mas que não havia falhado de facto, e novamente no canal de fallback. Para o OTP, isso é especialmente prejudicial: o utilizador recebe dois códigos diferentes e não sabe qual usar. A solução é ter uma única fonte de verdade para o estado de entrega por mensagem, um registo de cada envio (guarde o ID de mensagem que a API devolve e verifique o status antes de reenviar) para que uma nova tentativa nunca resulte num segundo envio e — para o OTP — gerar o código uma única vez e reutilizá-lo em todos os canais da cadeia, de forma que qualquer mensagem que chegue contenha um código válido.
Custo e experiência diminuem na hierarquia.
Cada degrau da escada tem uma economia diferente e uma experiência de utilizador distinta. O failover não é gratuito — pode significar uma mensagem com menos personalização ou um custo unitário mais alto. Isso é compreensível: um SMS um pouco mais caro que chega ao destino é melhor do que uma mensagem gratuita do WhatsApp que não chega. Mas significa que você deve monitorizar a sua taxa de failover. Se 40% do tráfego estiver a ser encaminhado para o último degrau, o problema está na origem — dados de capacidade incorretos, um canal primário mal configurado — e você deve corrigir a causa em vez de pagar pelo sintoma.
A API omnicanal da BroadNet implementa toda a gama de recursos — verificação de capacidade, failover condicional, código OTP partilhado e análises por canal — por meio de uma única chamada de API, e devolve um ID de mensagem para cada envio para que as suas novas tentativas verifiquem o status em vez de enviar duas vezes (veja idempotência e novas tentativas seguras). Você descreve a mensagem e a prioridade; a plataforma cuida da orquestração.
Teste os caminhos de falha
O motivo mais comum para uma estratégia de failover não funcionar em produção é que o caminho de failover nunca foi testado — ele foi escrito, implementado e nunca acionado até que ocorresse uma interrupção real. Crie testes sintéticos que forcem cada modo de falha (desabilite o canal primário, simule um timeout, injete um DLR negativo) e verifique se a mensagem ainda chega. Um caminho de failover que você não testou é um caminho de failover que você não tem.