Dois textos para a mesma pessoa depois de uma falha no pior momento

O momento arriscado era aquele entre a mensagem de texto sair e o nosso próprio sistema anotar que ela tinha saído.

A ideia era simples. Quando um job automatizado termina, mandar uma mensagem de texto de verdade para uma pessoa. Uma linha de log que ninguém está olhando não faz isso, e uma luz verde numa aba de navegador que já foi fechada também não. Uma mensagem curta que chega até alguém mesmo quando a pessoa parou de prestar atenção na execução.

Estávamos construindo isso durante uma virada de produção, ou seja, a mudança do trabalho real da configuração antiga para a nova. Achávamos que a parte difícil já estava resolvida. Mover a tarefa de envio para o novo worker com cuidado, verificar e manter o caminho antigo escutando como reserva, só por precaução. Esse plano resolvia o problema que estávamos vigiando.

Não nos ocorreu que a fila de mensagens tinha um risco próprio, separado, por baixo. A fila é a peça responsável por carregar essa versão mais segura do envio. Só encontramos o risco depois de ficar tempo suficiente com o modo de falha para fazer uma pergunta mais específica: o que acontece se o processo que cuida disso falhar exatamente no momento entre a mensagem sair e o nosso sistema registrar que ela saiu?

Dois fatos que parecem um só

Esse intervalo passa despercebido porque as duas metades soam como “enviado”. O provedor de mensagens externo aceitar um pedido é um fato. O nosso sistema terminar o registro e marcar o job como concluído é outro fato, um instante depois.

Digamos que uma falha caia entre esses dois momentos e o job seja repetido. Do ponto de vista do sistema, nada foi registrado ainda, então ele tenta de novo. O provedor aceita a segunda tentativa também. A mesma mensagem sai duas vezes, para uma pessoa de verdade, por causa de um erro que só existiu no espaço entre dois eventos que pareciam ser um só.

Por que um único marcador no final não resolve

Um único marcador gravado só depois que tudo terminou não fecharia esse intervalo, porque a falha acontece antes de esse marcador ser gravado. A correção precisava de dois sinais separados:

• Uma reserva de curta duração, definida antes de o pedido externo sair, para que uma nova tentativa quase simultânea não duplique algo que já está em andamento.
• Um marcador de longa duração, definido só depois que o provedor confirma de fato que recebeu a mensagem.

Dois fatos, registrados em dois momentos diferentes, porque são dois eventos diferentes, separados por uma janela real onde uma falha pode cair.

O que conferir na sua própria configuração

Se um processo seu conversa com um serviço externo, olhe o espaço entre “o serviço externo disse sim” e “o nosso sistema anotou que isso está feito”. Se as duas coisas acontecem num só passo, com um marcador definido apenas no final, uma falha no meio pode fazer uma nova tentativa repetir exatamente aquilo que você queria tornar seguro. Pode ser uma mensagem reenviada, uma cobrança feita duas vezes ou uma notificação duplicada. Coloque um marcador de cada lado desse intervalo, para que uma nova tentativa saiba a diferença entre “nunca aconteceu” e “já aconteceu, só não foi registrado ainda”.