Tentativas de reenvio de SMS transacionais: quando repetir, parar ou rever um envio

O problema: uma falha técnica nem sempre justifica outro SMS

Uma política de tentativas de reenvio de SMS transacionais estabelece o que fazer quando o resultado de um envio não é conclusivo ou indica um problema. O seu objetivo não é maximizar o número de tentativas, mas sim maximizar a probabilidade de uma mensagem ainda útil chegar sem criar duplicados, confusão para o destinatário ou tráfego desnecessário.

O ponto de partida é distinguir os estados técnicos disponíveis. A aceitação de um pedido por uma plataforma, a aceitação posterior por uma operadora e uma entrega reportada são eventos diferentes. Por exemplo, um estado equivalente a «sent» pode significar que uma operadora upstream aceitou a mensagem, e não que esta chegou ao terminal.

Por isso, um timeout de uma integração, uma resposta tardia ou uma atualização de estado incompleta não devem ser automaticamente transformados num novo SMS. Antes de repetir, o sistema deve determinar se a primeira mensagem pode ter sido aceite ou se continua em processamento.

• Não utilize a ausência imediata de um DLR como prova de falha definitiva.
• Não equipare a aceitação pelo fornecedor ou pela operadora à receção confirmada no telemóvel.
• Não trate todos os estados de erro como uma causa transitória.
• Não priorize o volume de tentativas de reenvio em detrimento da utilidade da mensagem e da experiência do destinatário.

Separe três decisões: transporte, negócio e encerramento

Um desenho robusto separa a mensagem lógica da tentativa técnica. A mensagem lógica é a intenção de negócio, como confirmar uma operação, avisar sobre uma alteração ou entregar um código de utilização única. Uma tentativa técnica é uma execução concreta para transportar essa intenção através de uma ligação, fornecedor ou rota disponível.

A tentativa de reenvio de transporte consiste em voltar a executar tecnicamente a mesma mensagem lógica sob regras delimitadas. Pode ser adequada quando existe uma causa documentada e potencialmente transitória, a mensagem continua a ser útil e o risco de já existir um envio ativo está controlado.

O reenvio de negócio é diferente: gera uma nova comunicação para o destinatário. Deve ser regido por regras de produto e de experiência, e não por um erro isolado de rede. Por exemplo, pedir um novo OTP pode invalidar o anterior, alterar a expiração e exigir a supressão de pedidos repetidos.

O encerramento definitivo indica que não serão feitas mais tentativas para essa unidade lógica. Pode ocorrer por expiração, evidência de rejeição definitiva, esgotamento do limite de tentativas, risco elevado de duplicação ou necessidade de revisão operacional.

• Mensagem lógica: a notificação que o negócio pretende comunicar.
• Tentativa técnica: uma execução individual para entregar essa mensagem lógica.
• Tentativa de reenvio de transporte: nova execução técnica sob a mesma intenção.
• Reenvio de negócio: nova notificação, potencialmente com novo conteúdo ou nova validade.
• Encerramento: decisão explícita de não continuar a enviar.

Defina primeiro a janela de utilidade

A primeira condição de qualquer política deve ser a janela de utilidade: o intervalo durante o qual receber o SMS continua a ter valor para o destinatário e para o processo. Um aviso de evento, uma confirmação de operação e um OTP podem ter janelas muito diferentes. Não existe uma duração universal que sirva para todos os casos.

A expiração técnica configurada numa plataforma de mensagens pode limitar durante quanto tempo uma mensagem permanece em fila antes de deixar de ser enviada. Contudo, essa configuração não substitui a decisão de negócio. O sistema emissor deve impor uma data ou hora de expiração coerente com a finalidade da mensagem.

Quando a janela termina, a ação prudente é parar as tentativas de reenvio. Entregar uma alerta tarde pode ser inútil; entregar um OTP tarde pode causar confusão ou levar o utilizador a introduzir um código que já não é válido.

• Defina uma expiração por tipo de mensagem antes de configurar tempos de espera e número de tentativas.
• Avalie a utilidade na perspetiva do destinatário, e não apenas pela disponibilidade da rota.
• Impeça o início de uma tentativa se já não houver tempo suficiente para a mensagem cumprir o seu propósito.
• Registe a expiração como motivo de encerramento, e não como uma falha técnica genérica.

Classifique o resultado antes de decidir

Uma política operacional precisa de uma classificação própria, estável e auditável. Não deve depender apenas dos rótulos de estado de uma integração específica. O objetivo é traduzir o resultado disponível numa decisão: parar, aguardar, repetir de forma controlada ou rever.

As rejeições definitivas são resultados para os quais a evidência disponível indica que repetir de imediato não resolverá o problema. Uma falha potencialmente transitória é aquela em que a causa documentada permite considerar uma nova tentativa dentro da janela de utilidade. A aceitação sem resultado final exige espera e reconciliação antes de enviar outra cópia. O estado incerto exige máxima prudência, porque a primeira mensagem pode ter avançado embora a aplicação não tenha recebido confirmação conclusiva.

Um estado equivalente a «undelivered» fornece evidência de que a mensagem não foi entregue, mas não determina uma causa única. Podem existir vários motivos, incluindo filtragem de conteúdo pela operadora ou disponibilidade do terminal. Por isso, também não transforma automaticamente a tentativa de reenvio na ação correta.

• Rejeição definitiva: parar e classificar para revisão ou correção.
• Falha potencialmente transitória: avaliar uma tentativa de reenvio limitada.
• Aceitação sem resultado final: aguardar uma janela de reconciliação.
• Estado incerto: não duplicar sem verificar referências, eventos tardios e expiração.
• Entrega reportada: encerrar o fluxo técnico, sem assumir mais evidência do que a disponível.

Não confunda DLR, aceitação e receção no terminal

Os recibos de entrega e os callbacks de estado são elementos valiosos para a operação, mas devem ser interpretados de acordo com aquilo que realmente comprovam. Uma plataforma pode informar que aceitou o pedido; um estado de envio pode indicar aceitação por uma operadora upstream; e um DLR pode comunicar um resultado posterior. São sinais operacionais diferentes.

A receção independente no terminal não deve ser inferida apenas porque um fornecedor aceitou um pedido ou porque existe um estado de envio para a rede. Mesmo quando existe um estado de entrega reportada, a política deve descrevê-lo com precisão como evidência reportada pela cadeia de mensagens disponível, e não como prova absoluta de leitura ou ação por parte do utilizador.

Esta distinção é essencial para evitar dois erros opostos: repetir uma mensagem que provavelmente já avançou ou declarar sucesso de negócio quando apenas é conhecido um estado de transporte.

• Conserve o significado original de cada estado recebido.
• Modele separadamente o sucesso de transporte, a entrega reportada e o sucesso de negócio.
• Evite usar um DLR como prova de consentimento, identidade, titularidade do número ou leitura da mensagem.
• Defina que evidências são suficientes para encerrar cada tipo de fluxo.

Critérios operacionais para autorizar uma tentativa de reenvio

Uma tentativa de reenvio deve exigir condições cumulativas, e não apenas um único sinal de erro. No mínimo, avalie a causa documentada, o tempo já decorrido, a criticidade da mensagem, o risco de duplicação e as restrições aplicáveis ao destino ou ao remetente.

A causa deve ser interpretável. Se não houver uma causa clara ou existir uma referência de fornecedor pendente, trate o caso como incerto e priorize a reconciliação. O tempo decorrido deve ser comparado com a janela de utilidade e com um período de espera concebido para permitir atualizações tardias. A criticidade pode justificar uma revisão mais rápida, mas não elimina o risco de duplicar uma notificação.

Também é conveniente considerar se o conteúdo, o identificador do remetente ou o destino podem estar relacionados com o resultado. Um erro de entrega não demonstra, por si só, qual destes elementos causou o problema. Se existir um padrão persistente, deve rever-se a configuração, o conteúdo, os eventos e a conectividade, em vez de repetir indefinidamente.

• A causa disponível está documentada e é compatível com um comportamento transitório?
• A mensagem continua dentro da sua janela de utilidade?
• Existe um identificador do fornecedor ou uma atualização pendente que possa confirmar o estado?
• O destinatário poderá receber duas cópias se a tentativa for repetida agora?
• A mensagem é suficientemente crítica para justificar o risco residual?
• Existe uma restrição recorrente por destino, remetente ou conteúdo que exija revisão?

Conceba uma escala de tentativas de reenvio com condições explícitas de paragem

Uma escala de tentativas de reenvio deve ser definida por tipo de mensagem, e não como uma regra global. Deve especificar o máximo de tentativas técnicas, a espera entre elas, a expiração absoluta, as causas admissíveis e as condições de paragem. Se uma destas peças não estiver definida, o comportamento ficará exposto a decisões improvisadas.

As esperas devem permitir a receção de eventos e callbacks tardios antes de gerar outra cópia. Os callbacks HTTP podem chegar fora de ordem e com variações de latência; algumas transições podem ocorrer muito próximas entre si. Por isso, uma automatização não deve decidir apenas com base no primeiro evento observado nem no primeiro timeout local.

O limite de tentativas deve ser baixo e fundamentado para o caso de utilização. Se a degradação persistir, mais repetições podem aumentar duplicados, custos operacionais e frustração sem corrigir a causa. O último resultado deve conduzir ao encerramento ou à revisão, e não a um ciclo indefinido.

• Estabeleça um máximo de tentativas técnicas por mensagem lógica.
• Defina uma espera mínima de reconciliação antes de cada nova tentativa.
• Aplique uma expiração absoluta que prevaleça sobre qualquer tentativa de reenvio pendente.
• Permita tentativas de reenvio apenas para causas previamente aprovadas.
• Pare o fluxo perante entrega reportada, rejeição definitiva, expiração, risco elevado de duplicação ou esgotamento do limite.
• Envie os casos repetidos ou inconclusivos para revisão operacional.

OTP: coordene entrega, expiração e segurança

Os OTP e outros segredos de autenticação exigem uma política mais rigorosa. Um segredo fora de banda tem vida curta e é entregue por um canal independente. Se o código já expirou, uma tentativa de reenvio de transporte não acrescenta valor e pode piorar a experiência.

A validade do código, o limite de tentativas de autenticação e a supressão de pedidos repetidos devem funcionar como um conjunto. Quando é gerado um novo código, o sistema deve decidir explicitamente o que acontece ao anterior, que tentativa técnica continua associada a cada código e que mensagens ficam suprimidas. Não permita que a camada de transporte continue a reenviar um código que o backend de autenticação já considera inválido.

Os fluxos por PSTN/SMS também exigem alternativas de autenticação e controlos de risco adequados ao contexto. Cobertura limitada, alterações de dispositivo ou SIM, portabilidade do número e comportamentos anómalos são exemplos de sinais que podem justificar controlos adicionais. Reenviar SMS não deve tornar-se a resposta automática a uma degradação persistente.

As respostas dirigidas ao utilizador devem ser prudentes, especialmente na autenticação e na recuperação de conta. Evite mensagens que revelem desnecessariamente se uma conta existe ou qual é o seu estado.

• Associe cada OTP a uma expiração de negócio inequívoca.
• Não tente reenviar um OTP após a sua expiração.
• Controle pedidos repetidos para reduzir fadiga e tráfego desnecessário.
• Aplique limitação de taxa às tentativas de autenticação quando apropriado.
• Defina alternativas de autenticação para casos em que o SMS não seja adequado ou não esteja disponível.
• Mantenha respostas externas genéricas quando necessário para evitar enumeração de contas.