Idempotence

Une opération est idempotente si la faire deux fois a le même effet que la faire une fois. Une clé d'idempotence sur une demande de paiement permet de réessayer sans débiter le client deux fois.

Où on le retrouve dans les vrais systèmes

  • Workers en arrière-plan

    Les workers absorbent le travail lent : e-mails, redimensionnement d'images, rapprochement de paiements. La livraison est au-moins-une-fois : les traitements doivent être idempotents, sinon les doublons produisent deux fois leurs effets.

    En production : Celery, Sidekiq, AWS Lambda event source, Kubernetes Jobs

  • File de messages

    Une file absorbe les pics : l'API répond dès que le message est stocké, et les workers vident l'arriéré à leur rythme. Les files standard livrent au moins une fois et peuvent réordonner ; les files FIFO gardent l'ordre mais plafonnent le débit. Les messages qui échouent à répétition partent en dead-letter.

    En production : Amazon SQS, RabbitMQ, Azure Service Bus, Google Cloud Tasks

  • Prestataire de paiement

    Les appels prennent des centaines de millisecondes, une petite part échoue de façon passagère, et le prestataire te limite. Ne débite jamais deux fois : envoie une clé d'idempotence avec chaque requête, réessaie avec backoff, et sors l'appel du chemin de la requête quand c'est possible.

    En production : Stripe, Adyen, PayPal, Moneris, Square

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable