Estratégias de Fallback para Notificações Críticas

Seu usuário acabou de fazer um Pix de R$ 10.000. O WhatsApp da sua empresa está fora do ar. O usuário não recebe confirmação. Liga para o suporte em pânico: "Cadê meu dinheiro?!"

Esse cenário não é hipotético. Acontece toda semana em alguma empresa brasileira. E a solução se chama fallback: quando o canal primário falha, outro assume automaticamente.

Neste guia, vamos cobrir estratégias reais de fallback que funcionam em produção.

Por Que Ter Apenas Um Canal é Risco

Nenhum canal de comunicação tem 100% de uptime. Veja as taxas reais de entrega no Brasil:

Canal	Taxa de Entrega Típica	Motivos de Falha
Email	95-98%	Spam filter, bounce, caixa cheia
SMS	94-97%	Número inválido, operadora fora, cobertura
WhatsApp	92-96%	App desinstalado, número errado, quota Meta
Push	70-85%	Notificações desativadas, app desinstalado
In-App	60-80%	Usuário precisa estar online

A matemática do desastre:

• 1 canal com 95% de entrega = 5% de falha
• Fallback para 2 canais = 0.25% de falha (95% × 5%)
• Fallback para 3 canais = 0.0125% de falha

Com três canais, você vai de 5.000 falhas em 100k envios para 12 falhas. A diferença é brutal.

Classificação de Criticidade

Nem toda notificação merece três tentativas. Classifique por criticidade:

🔴 Crítica (Fallback obrigatório, 3 canais)

• Alertas de fraude e segurança
• Códigos 2FA/OTP
• Confirmação de transações financeiras (Pix, TED)
• Alertas de saldo negativo
• Bloqueio de conta

SLA: Entrega em < 30 segundos

🟡 Importante (Fallback recomendado, 2 canais)

• Status de pedido (confirmação, envio, entrega)
• Fatura disponível
• Lembrete de pagamento
• Atualização de cadastro

SLA: Entrega em < 5 minutos

🟢 Informativa (Sem fallback necessário)

• Newsletter
• Promoções
• Dicas de uso
• Conteúdo educativo

SLA: Best effort (horas ou dias)

Padrão 1: Cascata Simples (Waterfall)

O mais comum. Tenta canal por canal em sequência.

WhatsApp → (falha após 30s) → SMS → (falha após 60s) → Email

Implementação na Notifica

// Workflow configurado no Dashboard:
// Nome: "Confirmação de Pix"
// Criticidade: Alta

await notifica.trigger('pix-confirmation', {
  to: {
    subscriberId: usuario.id,
    phone: usuario.telefone,
    email: usuario.email,
  },
  payload: {
    valor: 'R$ 10.000,00',
    origem: 'João Silva',
    dataHora: '26/02/2026 14:30',
    comprovante: 'https://...',
  },
});

// O workflow "pix-confirmation" no Dashboard:
// Passo 1: WhatsApp (timeout: 30s)
//   → Sucesso: Fim
//   → Falha: Passo 2
// Passo 2: SMS (timeout: 60s)
//   → Sucesso: Fim
//   → Falha: Passo 3
// Passo 3: Email
//   → Sucesso: Fim
//   → Falha: Alerta interno (Slack/PagerDuty)

Vantagens

• ✅ Simples de implementar e debugar
• ✅ Previsível — sempre na mesma ordem
• ✅ Fácil de monitorar

Desvantagens

• ❌ Latência acumulada (30s + 60s = 90s no pior caso)
• ❌ Não considera preferência do usuário
• ❌ Custo fixo por tentativa

Padrão 2: Preferência do Usuário + Fallback

Respeita a escolha do usuário para canal primário, com fallback automático.

Canal preferido do usuário → (falha) → Próximo melhor canal → (falha) → Email

Implementação

// Buscar preferências do usuário
const prefs = await notifica.subscribers.getPreferences(usuario.id);
// { preferredChannel: 'sms', channels: { sms: true, whatsapp: true, email: true } }

// O workflow da Notifica automaticamente:
// 1. Verifica canal preferido
// 2. Envia por ele
// 3. Se falhar, tenta o próximo habilitado
// 4. Respeita opt-outs (se desativou WhatsApp, pula)

Vantagens

• ✅ Respeita a vontade do usuário (melhor UX)
• ✅ Compliance com LGPD (consentimento por canal)
• ✅ Reduz taxa de bloqueio/report

Desvantagens

• ❌ Mais complexo de configurar
• ❌ Canal preferido pode ser o mais lento

Padrão 3: Envio Paralelo (Multi-blast)

Para notificações ultra-críticas, envia em todos os canais simultaneamente.

WhatsApp + SMS + Email → tudo ao mesmo tempo

Quando Usar

• Alerta de fraude com cartão
• Acesso não autorizado à conta
• Transação suspeita acima de threshold

Implementação

// Workflow "fraud-alert-critical"
// Modo: Parallel (todos os canais ao mesmo tempo)

await notifica.trigger('fraud-alert-critical', {
  to: {
    subscriberId: usuario.id,
    phone: usuario.telefone,
    email: usuario.email,
  },
  payload: {
    tipo: 'Compra online suspeita',
    valor: 'R$ 3.500,00',
    local: 'Site internacional',
    linkConfirmar: 'https://...',
    linkBloquear: 'https://...',
  },
  // Forçar envio em todos os canais disponíveis
  overrides: {
    workflow: { mode: 'parallel' },
  },
});

Vantagens

• ✅ Latência mínima — pelo menos um canal entrega rápido
• ✅ Cobertura máxima
• ✅ Crítico para segurança

Desvantagens

• ❌ Custo mais alto (paga por todos os canais)
• ❌ Usuário recebe mensagem duplicada (irritante se não for realmente crítico)
• ❌ Use com parcimônia

Padrão 4: Fallback Inteligente (com Delay Progressivo)

Espera um tempo antes de fazer fallback, considerando que o canal primário pode estar apenas lento.

WhatsApp → espera 30s → não confirmou entrega? → SMS → espera 120s → Email

Diferencial

Em vez de considerar "falha" quando a API retorna erro, considera "falha" quando não há confirmação de entrega (delivery receipt) dentro do timeout.

Isso é mais inteligente porque:

• O WhatsApp pode aceitar a mensagem (status 200) mas não entregar (celular offline)
• O SMS pode ser aceito pelo agregador mas não chegar na operadora

// Configuração no workflow da Notifica:
// 
// Passo 1: WhatsApp
//   Trigger: notification.sent
//   Esperar por: notification.delivered (webhook do BSP)
//   Timeout: 30 segundos
//   Se não receber delivered em 30s → Passo 2
//
// Passo 2: SMS
//   Trigger: notification.sent
//   Esperar por: notification.delivered (DLR do provedor)
//   Timeout: 120 segundos
//   Se não receber delivered em 120s → Passo 3
//
// Passo 3: Email (sempre entrega, pode ir para spam)

Padrão 5: Fallback por Provedor (Mesmo Canal)

Às vezes o problema não é o canal, é o provedor. Tenha redundância dentro do mesmo canal:

SMS (Zenvia) → falha → SMS (Twilio) → falha → SMS (HTTP custom)

Implementação com BYOP

// Na Notifica, configure múltiplos provedores SMS:
// Provider 1: zenvia-primary (prioridade 1)
// Provider 2: twilio-backup (prioridade 2)
// Provider 3: custom-http (prioridade 3)

// O sistema automaticamente tenta o próximo provedor se o primário falhar
// Sem mudança de código — configuração pura no Dashboard

Caso Real

Em janeiro de 2026, a Zenvia teve uma indisponibilidade de 2 horas que afetou envios de SMS. Clientes da Notifica com fallback para Twilio configurado não perceberam.

Anti-Padrões: O Que NÃO Fazer

❌ Retry infinito no mesmo canal

// ERRADO: vai ficar tentando pra sempre
while (!enviado) {
  await enviarSMS(numero, mensagem);
}

Correto: Máximo 3 tentativas com backoff exponencial, depois mude de canal.

❌ Fallback sem deduplicação

Se o WhatsApp demorou mas eventualmente entregou, e você já mandou SMS como fallback, o usuário recebe duas mensagens.

Correto: Use event_id para deduplicar e verifique status antes de fazer fallback.

❌ Mesmo conteúdo em todos os canais

O conteúdo de um email é diferente de um SMS (160 caracteres). Adapte.

// Templates diferentes por canal para o mesmo workflow:
// WhatsApp: Mensagem rica com botões e imagem
// SMS: Texto curto e direto (até 160 chars)
// Email: Layout completo com HTML

❌ Fallback para canal que o usuário desativou

Se o usuário fez opt-out de SMS, não use SMS como fallback. Isso viola a LGPD.

A Notifica respeita automaticamente as preferências do subscriber — canais desativados nunca são usados como fallback.

Monitoramento de Fallbacks

Métricas Importantes

• Fallback rate — % de envios que precisaram de fallback (ideal: < 5%)
• Fallback success rate — % de fallbacks que entregaram com sucesso
• Latência total — tempo do trigger até entrega final (incluindo fallbacks)
• Custo de fallback — quanto você gasta extra com canais secundários

Dashboard na Notifica

O Dashboard mostra:

• Quantos workflows ativaram fallback na última hora/dia/semana
• Qual canal primário mais falha (indica problema no provedor)
• Latência média por caminho (WhatsApp direto vs. WhatsApp→SMS)

Tabela de Decisão Rápida

Tipo de Notificação	Canal Primário	Fallback 1	Fallback 2	Modo
2FA/OTP	SMS	WhatsApp	Email	Cascata
Fraude	WhatsApp + SMS	Email	—	Paralelo
Status de pedido	WhatsApp	Email	SMS	Preferência
Fatura	Email	WhatsApp	SMS	Cascata
Marketing	Email	—	—	Sem fallback
Alerta de saldo	WhatsApp	SMS	Email	Cascata

Conclusão

Fallback não é over-engineering. É seguro contra falha para a comunicação mais importante da sua empresa.

Implemente de forma progressiva:

1. Semana 1: Identifique suas notificações críticas
2. Semana 2: Configure fallback cascata simples
3. Semana 3: Adicione monitoramento e alertas
4. Semana 4: Otimize com fallback inteligente e multi-provedor

Seus usuários não sabem (e não devem saber) que houve fallback. Eles só sabem que a mensagem chegou. E é isso que importa.

---

Quer configurar fallbacks sem código? O workflow visual da Notifica permite criar lógicas de fallback complexas com drag-and-drop. Teste grátis com sua conta e veja a documentação de workflows.