a messaggistica a canale singolo presenta un unico punto di guasto. WhatsApp può subire un'interruzione, un utente può risultare irraggiungibile su RCS, la linea di trasmissione dell'operatore può subire un degrado, un modello può essere rifiutato a metà campagna. Una strategia di failover multicanale considera "consegnare questo messaggio a questa persona" come obiettivo e il canale come mezzo intercambiabile. Ecco come progettarne una che sia realmente affidabile.
Definire la gerarchia dei canali per tipo di messaggio
Non esiste un ordine universale: la sequenza corretta dipende dal messaggio. Alcuni suggerimenti di buon senso: per l'autenticazione, prima WhatsApp o RCS (ricchi, personalizzati, veloci), poi SMS e infine OTP vocale. Per le notifiche transazionali, prima RCS o WhatsApp per un'esperienza personalizzata, poi SMS come soluzione di ripiego garantita. Per gli avvisi urgenti, iniziare con gli SMS per la loro ampia diffusione e aggiungere la chiamata vocale come ulteriore opzione. Definisci la sequenza in modo ponderato, per ogni tipo di messaggio, e annotala.
Il failover deve essere condizionale, non cieco.
- Errore di funzionalità: l'utente non è raggiungibile sul canale (nessun RCS configurato, nessun account WhatsApp). Interrompere immediatamente la connessione; non attendere.
- Errore di consegna: il canale ha accettato il messaggio, ma il DLR lo segnala come non consegnato. Fallimento a causa della ricevuta negativa.
- Errore di timeout: nessuna conferma di consegna entro la scadenza specificata per il tipo di messaggio (ristretta per i messaggi OTP, più flessibile per le notifiche). L'operazione viene annullata allo scadere del tempo.
- Guasto del provider: il canale stesso è inattivo. Rilevalo tramite il monitoraggio del tasso di errore e, in caso di guasto, esegui il failover dell'intero canale per tutto il traffico, non messaggio per messaggio.
Attenzione alla doppia consegna
Il sottile bug presente in ogni sistema di failover consiste nell'invio del messaggio due volte: una volta sul canale lento ma non effettivamente guasto e una seconda volta sul canale di fallback. Per i sistemi OTP questo è particolarmente problematico: l'utente riceve due codici diversi e non sa quale utilizzare. La soluzione consiste nell'utilizzare un'unica fonte di verità per lo stato di consegna di ciascun messaggio, un registro di ogni invio (conservare l'ID messaggio restituito dall'API e verificarne lo stato prima di qualsiasi reinvio) in modo che un tentativo di ritrasmissione non generi mai un secondo invio e, per i sistemi OTP, generare il codice una sola volta e riutilizzarlo su tutti i canali della rete, in modo che qualsiasi messaggio in arrivo contenga un codice valido.
Sia il costo che l'esperienza si spostano verso il basso nella scala
Ogni gradino della scala ha un'economia e un'esperienza utente diverse. Il passaggio al livello successivo non è gratuito: può significare un messaggio meno personalizzato o un costo unitario più elevato. Questo è giusto e corretto: un SMS leggermente più costoso che arriva a destinazione è meglio di un messaggio WhatsApp gratuito che non arriva. Ma significa che è necessario monitorare il tasso di passaggio al livello successivo. Se il 40% del traffico non riesce a raggiungere l'ultimo gradino, il problema è a monte (dati di capacità errati, un canale primario configurato in modo errato) ed è necessario risolvere la causa anziché pagare per il sintomo.
L'API omnicanale di BroadNet implementa l'intera gamma di funzionalità – verifica delle capacità, failover condizionale, codice OTP condiviso e analisi per canale – tramite una singola chiamata API, e restituisce un ID messaggio per ogni invio così che i tuoi tentativi verifichino lo stato invece di inviare due volte (vedi idempotenza e retry sicuri). Tu descrivi il messaggio e la priorità; la piattaforma si occupa dell'orchestrazione.
Verifica i percorsi di errore
Il motivo più comune per cui una strategia di failover non funziona in produzione è che il percorso di failover non è mai stato testato: è stato scritto, implementato, ma non è mai stato attivato fino a un'interruzione reale. Crea test sintetici che forzino ogni modalità di errore (disabilita il canale primario, simula un timeout, inietta un DLR negativo) e verifica che il messaggio venga comunque recapitato. Un percorso di failover che non hai testato è un percorso di failover che non hai.