Expiração de notificações SMS A2P: como evitar avisos tardios

O que significa uma notificação ter perdido a validade

Uma notificação perde a validade quando deixa de cumprir o propósito para o qual foi criada. Um aviso pode continuar tecnicamente enviável e, ainda assim, tornar-se confuso, redundante ou prejudicial se chegar depois do evento que deveria comunicar.

A validade é uma decisão de produto e de operações: determina até quando faz sentido tentar iniciar o envio. Não deve ser confundida com a expiração interna de uma fila nem com os parâmetros de validade que um fornecedor ou uma rede possam aceitar. Os sistemas e os contratos podem oferecer comportamentos diferentes; as fontes disponíveis não permitem afirmar que exista um prazo universal ou um mecanismo comum.

• Define o evento que justifica a mensagem e a ação que ela deve permitir ao destinatário.
• Estabelece quando uma entrega tardia deixa de ser útil ou pode induzir em erro.
• Documenta a política como uma regra de negócio própria, não como um valor padrão de SMS.

Classifica as notificações pelo impacto de uma entrega tardia

Não atribuas o mesmo limite a todas as notificações. Classifica-as de acordo com o seu propósito, o impacto de chegarem tarde e a possibilidade de uma comunicação posterior as substituir. A classificação deve ser acordada entre as equipas de produto e de operações e os responsáveis pelo processo que origina a mensagem.

Os avisos efémeros costumam depender de uma ação ou situação que muda rapidamente. As atualizações podem continuar a ser úteis durante mais tempo, mas tornar-se obsoletas se uma versão nova as substituir. Outras comunicações transacionais podem continuar a ser informativas mesmo se chegarem mais tarde; isso não elimina a necessidade de considerar o contexto e evitar duplicados.

• Efémera: determina que evento a torna inútil, como concluir ou cancelar a ação associada.
• Atualizável: identifica se uma notificação posterior substitui a anterior e como detetar essa substituição.
• Persistente: confirma que o conteúdo continua correto e útil após o atraso.
• Para cada classe, regista o propósito, a condição de obsolescência, o responsável e a conduta a adotar quando a validade termina.

Define o limite a partir de um evento de negócio

Define a hora de expiração a partir do evento que criou a notificação, e não de uma hora fixa ambígua. Por exemplo, uma regra pode depender do momento em que uma operação é iniciada, uma alteração é confirmada ou um pedido é cancelado. O ponto de partida exato depende do processo e deve ficar explícito.

Representa a regra como uma data e hora limite associada à notificação. Especifica o fuso horário utilizado pelo sistema, como são tratadas as alterações de estado posteriores e o que acontece se o evento de origem se repetir. Não pressuponhas que todos os componentes interpretam da mesma forma uma duração ou uma marca temporal.

• Guarda o identificador do evento de negócio e a hora em que ocorreu.
• Calcula a expiração a partir desse evento, segundo uma regra documentada.
• Antes do envio, volta a verificar se o evento continua válido ou se foi substituído.
• Garante que os componentes comparam as marcas temporais de forma coerente, incluindo o fuso horário.

Coordena a aplicação, as filas e o fornecedor

A política deve ser coerente ao longo de todo o percurso. A aplicação pode decidir que uma notificação já não é útil; a fila pode mantê-la ou encaminhá-la para processamento; o fornecedor pode aceitar um pedido e gerir a sua transmissão de acordo com as próprias capacidades e condições. Não pressuponhas que a expiração configurada num componente interrompe automaticamente os restantes.

Define onde cada controlo é aplicado e o que significa cada estado. Se a API ou a interface do fornecedor disponibilizar um parâmetro relacionado com a validade, confirma o seu significado, os limites e o âmbito na documentação técnica e contratual aplicável. As informações disponíveis não permitem especificar nomes de parâmetros, unidades, limites ou comportamentos comuns.

• Na aplicação, decide se a mensagem continua válida antes de criar ou enviar o pedido.
• Em cada fila própria, define como detetar e descartar elementos expirados antes de os encaminhar para o sistema seguinte.
• Na integração, confirma quais os parâmetros de expiração que o fornecedor realmente aceita, se aceitar algum.
• Esclarece qual o estado que confirma a receção do pedido e qual, se existir, informa sobre uma etapa posterior da entrega.
• Evita que uma fila volte a tentar enviar mensagens obsoletas sem voltar a consultar o estado do negócio.

Trata resultados pendentes ou incertos

A aceitação de um pedido, por si só, não prova que o destinatário recebeu a mensagem. Um estado pendente, ausente ou incerto também não permite concluir que a entrega falhou. A interpretação depende dos estados e das informações disponibilizadas pelo fornecedor; um DLR comunicado deve ser tratado como o estado reportado, não como uma verificação independente da receção no terminal.

Quando a validade termina depois de o fornecedor ter aceite o pedido, regista a situação de forma distinta de um descarte anterior ao envio. Evita reenviar automaticamente apenas por falta de um resultado: a primeira mensagem pode ter sido entregue e um duplicado pode chegar tarde. Define a resposta com a equipa de produto, considerando o impacto da duplicação, o estado observável e as opções reais de consulta ou acompanhamento.

• Separa os estados internos: expirado antes do envio, pedido aceite com resultado pendente e resultado desconhecido.
• Não interpretes a ausência de um DLR como prova de falha ou de entrega.
• Antes de tentar novamente, avalia o risco de duplicação e confirma que informações o fornecedor pode disponibilizar.
• Se não for possível resolver a incerteza, regista essa limitação e aplica uma política explícita, em vez de atribuir um resultado não confirmado.

Regista expirações e descartes de forma auditável

Um registo útil permite reconstruir o que aconteceu sem confundir uma decisão de negócio com uma falha de entrega. Conserva um motivo de descarte definido, um identificador que possa ser correlacionado entre sistemas e marcas temporais dos momentos relevantes. Os campos concretos dependem da tua arquitetura e das obrigações aplicáveis.

Limita os dados registados ao necessário para operar e auditar o processo. Evita incluir nos registos o conteúdo sensível do SMS se não for necessário para a finalidade operacional; aplica os controlos de acesso e de retenção pertinentes.

• Regista o identificador interno da notificação e uma referência que possa ser correlacionada com o pedido ao fornecedor.
• Anota quando foi criada, quando expirava e quando foi tomada a decisão de enviar ou descartar.
• Utiliza motivos distintos, por exemplo: evento concluído, mensagem substituída, expiração de negócio ou erro de configuração.
• Distingue o descarte anterior ao envio da expiração posterior à aceitação e do resultado desconhecido.
• Documenta qual componente tomou a decisão e que estado do fornecedor foi observado, se aplicável.

Mede as expirações por etapa, não como um único total

Um total agregado de mensagens expiradas pode ocultar problemas diferentes. Separar os descartes anteriores ao envio dos casos posteriores à aceitação e dos resultados desconhecidos ajuda a identificar se a política, a fila ou a integração precisam de ser revistas. As métricas são decisões de observabilidade de cada equipa, não requisitos que as fontes disponíveis atribuam a uma norma.

• Conta as notificações que expiram antes de serem entregues ao fornecedor.
• Conta separadamente os pedidos aceites cujo resultado continua pendente ou é desconhecido quando termina a validade.
• Agrupa as expirações por classe de mensagem, motivo e componente que tomou a decisão.
• Analisa a relação entre mensagens substituídas, descartadas e reenviadas para detetar regras incoerentes.
• Interpreta os números tendo em conta a definição de cada estado: não apresentes um DLR como uma verificação independente do terminal.

Testa a política com tráfego controlado

Antes de aplicar uma regra em larga escala, testa casos representativos num ambiente controlado ou com tráfego limitado e autorizado. O objetivo é verificar se cada sistema aplica a mesma decisão e se os registos permitem explicar o resultado. Não pressuponhas que um teste demonstra o comportamento de todas as rotas ou redes.

Inclui cenários de expiração antes da entrada na fila, durante a espera, de substituição por uma notificação nova e de aceitação pelo fornecedor sem um resultado conclusivo. Confirma os resultados observáveis disponíveis e documenta os limites do teste.

• Verifica o fluxo normal e cada motivo de descarte definido.
• Confirma que uma notificação obsoleta não é reenviada por uma fila sem uma nova verificação.
• Testa como são tratados os estados pendentes e incertos, sem os considerar automaticamente uma falha.
• Confirma que os identificadores e as marcas temporais permitem acompanhar o caso entre a aplicação, a fila e o fornecedor.
• Consulta a documentação técnica do fornecedor para quaisquer parâmetros de validade e regista o que não for possível verificar.
• Ajusta a política se o sistema descartar mensagens úteis ou permitir que avisos obsoletos continuem a avançar.