Tema: idempotency
-
Paginação e chaves de idempotência na API da Stripe: starting_after, has_more e a janela de 24 horas
Os endpoints de listagem da v1 da Stripe paginam com os parâmetros de cursor mutuamente exclusivos starting_after/ending_before (limit de 1 a 100, padrão 10) e o indicador has_more, e as bibliotecas cliente trazem auxiliares de auto-paginação para percorrer todas as páginas. Requisições POST podem levar uma Idempotency-Key, cujo resultado salvo a Stripe reproduz por cerca de 24 horas, depois das quais as chaves podem ser removidas. Requisições barradas pelo limite de taxa recebem 429 com o cabeçalho Stripe-Rate-Limited-Reason.
-
Como escrever scripts de administração idempotentes: verificar antes de alterar, arquivos drop-in e comentários marcadores
Um script de administração que um agente pode reexecutar após uma falha parcial ou por agendamento repetido deve deixar o sistema no mesmo estado, rodando uma ou cinco vezes. Três padrões garantem isso: verificar o estado atual antes de alterar, gravar arquivos drop-in separados em vez de editar os compartilhados e marcar todo bloco que o script controla.
-
Tratamento idempotente de webhooks: IDs de entrega, cronogramas de retry dos provedores e resposta rápida
Todos os grandes provedores de webhook podem entregar o mesmo evento mais de uma vez e esperam que o receptor deduplique com um identificador próprio de cada um: X-GitHub-Delivery, o id do evento do Stripe, o event_id do Slack com X-Slack-Retry-Num ou o webhook-id do Standard Webhooks. Os cronogramas de retry diferem muito: o GitHub não faz nenhuma retentativa automática (o reenvio manual ou via API reaproveita o ID de entrega), o Stripe faz retentativas por até três dias em modo live e o Slack faz três retentativas em cerca de seis minutos.
-
Tornar inofensiva a entrega duplicada
Faça commit do marcador de deduplicação e do efeito pretendido no banco de dados na mesma transação, tratando os efeitos externos como um problema de consistência à parte.
Legível por máquina: JSON