Quand une connexion coupe après l’envoi d’un événement, le producteur ne sait pas toujours si l’écriture a eu lieu. Redemander est normal ; écraser une autre réalité sous la même identité ne l’est pas.
01
Reconnaître une retransmission
Le composant rapproche l’identité et le contenu. Une retransmission identique peut retrouver son reçu ; un contenu différent sous la même identité doit être refusé.
02
Relier le reçu à la persistance
Le chemin décrit conserve événements et reçus dans une transaction. Un résultat de commit incertain doit rester incertain, plutôt que devenir un succès inventé.
03
Le producteur participe à la garantie
Pour éviter les pertes, le producteur conserve durablement les événements en attente tant que leur réception n’est pas confirmée. Une file de sortie locale peut jouer ce rôle.
04
Le journal n’est pas toute l’observabilité
Le stockage d’événements ne remplace pas les collecteurs, les tableaux de bord ou un dispositif WORM. La responsabilité visée est le contrat d’événement et de réception.
event_id + contenu
↓
écriture et reçu
↓
transmission répétée → même reçu
identité réutilisée avec autre contenu → refusEt face aux autres outils ?
Comparaison de périmètres, sans classement de performances. Références éditeurs consultées le 31 octobre 2026.
Grafana Loki
Loki agrège des journaux et permet de les interroger. SHAPER Logger vise le contrat d’événement et son reçu dans un service ; il ne remplace pas une plateforme complète d’observabilité.
Documentation de référence ↗Sources et références
Les mécanismes sont présentés avec leur périmètre d’utilisation. Leur qualification dans votre environnement reste une étape distincte. Les liens ci-dessous donnent accès aux références publiques disponibles.