Durante um pico de tráfego em uma data comercial importante, um cliente finaliza uma compra, mas a resposta do servidor demora tanto que o aplicativo assume falha e tenta novamente automaticamente. O pagamento já havia sido processado na primeira tentativa; a segunda apenas nunca deveria ter acontecido. Rolando Bonaccorsi, diretor de operações da Vert Analytics, descreve esse cenário como um dos erros mais caros e mais evitáveis em sistemas que lidam com dinheiro real.
O conceito que resolve esse problema chama-se idempotência: a garantia de que executar a mesma operação várias vezes produz exatamente o mesmo resultado da primeira execução, sem qualquer efeito colateral adicional acumulado a cada nova tentativa repetida pelo cliente ou pela própria rede instável.
O problema: a rede falha, mas ninguém sabe se o pagamento passou
O cenário mais traiçoeiro não é a rede falhar antes da operação, é falhar depois: o servidor processa o pagamento com sucesso, mas a resposta de confirmação se perde no caminho de volta até o cliente, que interpreta esse silêncio como falha e tenta a mesma cobrança novamente, sem saber que a primeira já havia sido concluída. Do ponto de vista de quem está diante da tela, indisponível de saber o que aconteceu no servidor, repetir parece a única atitude razoável a se tomar naquele momento.
Esse tipo de falha parcial é especialmente comum em sistemas sob alta carga, justamente nos momentos de maior volume de transações, como picos de vendas, em que qualquer cobrança duplicada gera reclamação em massa e prejuízo direto de reputação para a empresa envolvida. Assim, Rolando Bonaccorsi expõe que, multiplicado por milhares de transações simultâneas, um problema que parece raro isoladamente se torna estatisticamente inevitável em qualquer sistema de escala relevante.
A chave que resolve: gerada antes, não depois
Segundo Rolando Bonaccorsi, a solução prática mais adotada é a chave de idempotência: um identificador único, gerado pelo cliente antes de enviar a requisição, que acompanha aquela intenção específica de pagamento em qualquer tentativa subsequente de reenvio da mesma operação.
O servidor guarda essa chave junto com o resultado da primeira execução bem-sucedida. Se a mesma chave chegar novamente, o sistema simplesmente devolve a resposta já registrada, sem repetir a cobrança, reconhecendo que aquela tentativa específica já foi atendida em uma ocasião anterior, mesmo que o cliente não soubesse disso no momento do reenvio.
Nem toda operação precisa dessa proteção
Operações de leitura, como consultar um saldo ou buscar um pedido, já são naturalmente idempotentes, logo, repetir a mesma consulta várias vezes não altera nada no sistema, apenas devolve a mesma informação solicitada, sem qualquer risco associado a essa repetição natural do comportamento. Excluir um registro também costuma se comportar de forma parecida, já que excluir algo que já foi excluído não deveria gerar novo efeito colateral relevante.
O risco real se concentra em operações que criam ou alteram dados com efeito colateral financeiro ou irreversível, como processar pagamento, criar pedido ou debitar estoque. Rolando Bonaccorsi considera esse mapeamento prévio, identificando quais operações realmente precisam de chave de idempotência, etapa que evita tanto lacunas de proteção quanto complexidade desnecessária aplicada onde não faz diferença real, poupando esforço de engenharia para os pontos que efetivamente concentram risco financeiro relevante.
Onde aplicar primeiro?
Sistemas de pagamento brasileiros já incorporam essa proteção como padrão: o identificador único de cada cobrança Pix cumpre exatamente essa função, evitando que reenviar a mesma transação gere duplicidade, mesmo diante de instabilidade de rede entre instituições financeiras diferentes.
Empresas que ainda não implementaram esse padrão em seus próprios fluxos críticos de pagamento deveriam tratar essa lacuna como prioridade imediata, não como melhoria futura: o custo de implementar chave de idempotência é pequeno, comparado ao custo de reembolsar clientes cobrados duas vezes pelo mesmo produto, sem contar o desgaste de confiança que uma cobrança duplicada gera, mesmo depois de qualquer estorno ser processado corretamente.
