Idempotency-Key num POST
Pergunta
Um POST que cria um pagamento pode ser reenviado (timeout, retry do cliente). Como uma chave de idempotência resolve o risco de cobrar duas vezes?
Resposta esperada
O cliente gera um identificador único por operação (UUID) e o envia num header `Idempotency-Key`. O servidor, ao receber, checa um armazenamento (com TTL) por essa chave: se é a primeira vez, processa a operação, guarda o resultado associado à chave e responde; se a chave já existe, devolve o resultado guardado sem reprocessar. Assim, um retry do mesmo request produz a mesma resposta e um único pagamento. Detalhes que a resposta forte cita: a escrita da chave + operação precisa ser atômica (transação ou lock) pra evitar corrida entre dois retries simultâneos; a chave é por operação lógica, não por sessão; e há uma janela de expiração. GET/PUT/DELETE já são idempotentes por definição HTTP; o problema é específico de POST.
Por que perguntam isso
Pergunta sênior. Sinal de quem já implementou: mencionar a atomicidade entre gravar a chave e executar a operação (senão dois retries simultâneos furam).