Idempotence et exactly once
Progression
#Idempotence et le mirage du « exactly once »
Dans un réseau imparfait, les messages se perdent ou se dupliquent. La promesse « exactly once » est coûteuse et souvent illusoire; on raisonne plutôt en « at least once » avec idempotence, ou en « at most once » avec perte possible. L’idempotence rend une opération répétable sans changer le résultat final, ce qui permet des réessais sûrs.
En pratique, on combine des identifiants de déduplication, un stockage d’outbox qui persiste les événements avant de les publier, et des opérations côté serveur qui vérifient l’unicité. On préfère des modèles où l’état peut être reconstruit depuis un journal d’événements, ce qui simplifie la reprise après incident et la traçabilité.
#Animation: patterns concrets
Idempotency‑Key
Clé unique côté client
Dédup serveur
Table des requêtes traitées
Outbox
Écrire event dans la même TX
Consumer
Dédoublonner et appliquer
#Diagramme: création idempotente
Client
API
DB