Idempotência: proteger o cliente de erros invisíveis
Existe um tipo de bug silencioso, caro e constrangedor. Acontece porque alguém clicou duas vezes — e ninguém pensou no que aconteceria. Esse conceito tem nome: idempotência. Como BA você desenha fluxos que podem ou não proteger o usuário de duplicidade. Quando não protegem, o problema não é só técnico: é reputacional, financeiro e às vezes jurídico.
Cliente finaliza a compra e clica em "Confirmar pagamento". A internet oscila, a tela demora, ele clica de novo. Sem proteção você pode ter dois pedidos, duas cobranças, duas integrações. Usuários repetem ações o tempo todo; não é exceção, é comportamento humano. Repetir a mesma ação não deve gerar efeito adicional. Enviar a mesma requisição duas vezes deve dar o mesmo resultado que enviar uma vez. Confirmar pedido duas vezes continua um pedido confirmado. Sem idempotência, repetir gera duplicidade.
Quem define fluxo de confirmação e botão de ação crítica é influenciado pelo requisito. Se você escreve "ao clicar em confirmar, criar pedido e cobrar" e não considera "e se clicar duas vezes?", deixou lacuna. Desabilitar o botão após o clique ajuda, mas não resolve. O usuário pode atualizar a página; a conexão pode cair; o gateway pode fazer retry. Proteção de verdade é estrutural. Você integra com gateway externo, manda a requisição de cobrança, a resposta demora, seu sistema tenta de novo. O gateway pode processar duas vezes. Sem idempotência o cliente pode ser cobrado duas vezes — aí vem experiência ruim, suporte, chargeback.
Idempotência importa em criação de pedido, reserva de estoque, emissão de nota, envio de e-mail, cadastro, atualização de status crítico. Sempre que uma ação gera efeito único, vale perguntar: "O que acontece se essa requisição for repetida?" Requisito: "Ao confirmar pedido, reservar estoque." Se o pedido for criado duas vezes por repetição, você pode reservar estoque duas vezes e criar falta artificial. Buscar lista de produtos: repetir não estraga. Criar pedido: repetir pode ser desastre. Quanto mais transacional e irreversível a ação, mais idempotência importa.
Em microserviços a repetição é ainda mais provável — retentativas automáticas, fila, retry configurado. Repetição não é exceção; é cenário esperado. Em vez de só "Criar pedido e cobrar pagamento", algo como: "A operação de criação deve garantir unicidade por transação, evitando duplicidade em caso de repetição de requisição." Você não está definindo implementação; está exigindo proteção. Erro visível: tela quebra. Erro invisível: cobrança duplicada, pedido duplicado — costuma ser pior, aparece depois, em geral no financeiro. Você não precisa implementar chave idempotente; precisa levantar o risco.
Usuários repetem, redes falham, sistemas tentam de novo. Isso não vai mudar. O que muda é se o produto está preparado.
No próximo post: consistência eventual. Porque em sistemas distribuídos, "atualizar ao mesmo tempo" nem sempre é possível.
