Moteur de traitement de jobs idempotent
Un exécuteur de tâches de fond bâti sur l'hypothèse que chaque message peut arriver deux fois et que chaque worker peut mourir en pleine transaction. L'intéressant n'est pas la file — c'est la preuve que l'effet n'a eu lieu qu'une seule fois.
- LIVRAISON
- Au moins une fois, effet exactement une fois
- RÉSERVATION
- PostgreSQL, SKIP LOCKED
- REPRISE
- Backoff borné avec gigue
- TESTS
- Testcontainers, base réelle
- DÉCISIONS
- 9 ADR avec options écartées
index unique
une fois
↳ reprises épuisées → DEAD LETTER↳ clé dupliquée → sans effet, acquitté
LE POINT DIFFICILE
La clé de déduplication doit dériver de l'intention de l'appelant, pas des octets du message. Deux tentatives diffèrent dans leur charge utile ; l'intention, non.
CE QUE J'AI ÉCARTÉ
Les verrous sur Redis. Rapides, mais le verrou et l'écriture vivent dans deux domaines de panne distincts — la correction ne peut pas être à cheval sur deux systèmes.
CE QUE JE CORRIGERAIS À GRANDE ÉCHELLE
Le relais outbox garde le verrou de ligne pendant l'appel HTTP. Le passage à l’échelle consiste à réserver puis émettre avec un bail, en dehors de la transaction.