Messagerie transactionnelle

La messagerie transactionnelle est un ensemble de techniques architecturales qui assurent la cohérence entre les changements d'état locaux (OBD/cache) et les messages dans le courtier/bus. Objectif : « l'état est enregistré ↔ le message n'est ni perdu ni dupliqué » en cas d'échec, de rétroaction, de mise à l'échelle et de multitenance.

1) Sémantique d'expédition

At-most-once : rapide et bon marché, des pertes possibles, pas de prises.
At-least-once : ne pas perdre le message, les prises sont possibles → l'idempotence est nécessaire.
(Efficace) Exactly-once : il n'y a pas de pertes et pas de prises visibles pour les effets commerciaux, obtenu par une combinaison de techniques (outbox/inbox, transactions du vendeur/consumer, dedup).

2) Pourquoi les « deux pismos » sont dangereux

La logique naïve « d'abord écrire dans la base de données, puis envoyer dans le pneu » (ou vice versa) se déchire lors de la chute entre les étapes : les données sont fixes et l'événement est perdu ; soit l'événement est parti et il n'y a pas de données. La messagerie transactionnelle corrige cette lacune.

3) Modèles de base

3. 1 Outbox (fabricant)

Dans une transaction locale, nous enregistrons le changement d'entreprise et la ligne dans la table « outbox » ; un pablisher séparé lit un outbox et le poste dans un courtier avec des retraits et un backoff. Les pertes sont exclues ; les doublons sont éteints par l'idempotence chez les consommateurs.

3. 2 Inbox/Idempotent Consumer (consommateur)

Avant d'exécuter l'effet, le consumer fait 'INSERT' dans 'inbox (consumer, event_id)' comme clé primaire. Conflit de clé = événement déjà traité → ignoré. C'est ainsi que l'on obtient un « exactly-once efficace ».

3. 3 Read-Process-Write avec transaction offset

Modèle pour les pneus orientés log : le consumer lit le batch, dans la même transaction enregistre le changement d'entreprise et « l'offset passé ». Après le commit, le courtier considère les messages comme consommés. Cela élimine « lu → tombé → répété » sans prise dans l'effet.

3. 4 TSS/Sagas pour les effets interservices

Lorsque vous avez besoin d'un processus multi-shag cohérent, utilisez des TCC ou des sagas ; les messages sont le transport des commandes/événements et la transaction au niveau des étapes et des compensations.

4) Vendeurs et consumers idempotent

Produser : stable 'message _ id '/' idempotency _ key', la réémission avec la même clé ne crée pas de nouveaux effets chez les abonnés ; maintenir la séquence (sequence) par clé.
Consumer : 'inbox' + idempotence d'entreprise (upsert/merge, vérification de la dernière version/révision).

5) Ordre et causalité

Partez par clé professionnelle (par exemple, 'aggregate _ id', 'tenant _ id') pour que les événements d'un seul objet arrivent bien.
À l'intérieur du lot, gardez les numéros/horodatages successifs ; avec le redrave du DLQ, respecter « par clé et de façon cohérente ».
Si l'ordre global n'est pas critique, fournissez un ordre local par clé et fixez les invariants du domaine.

6) Offsets et fixation des effets

Option A : « Offset in DB »

Écrivez « le dernier offset traité (partition, offset) » dans la même transaction où vous modifiez vos données de domaine. Avec le restart, continuez à partir de l'offset suivant, en évitant les effets répétés.

Option B : « Transaction du courtier »

Certains courtiers prennent en charge l'enregistrement atomique des messages et des offsets dans le cadre d'une seule transaction du vendeur/consumer. Utiliser si disponible, mais toujours compléter l'idempotence sur le consommateur.

7) Retrai, backoff, DLQ

Ne répétez que les erreurs rétroactives (temporisations, 5xx), avec un backoff exponentiel et un jitter.
Non-rétroactif (schema/validation) - immédiatement dans le DLQ avec des métadonnées (tenant, clé, offset, cause).
Redrive de DLQ doser (batch, rate limit), vérifier le schéma avant de répéter, respecter l'ordre de la clé.

8) Multi-ténacité et régions

Incluez 'tenant _ id', 'plan', 'region' dans les métadonnées du message et les clés de lot.
Per-tenant fairness : limitez la publication/le traitement afin que le client « bruyant » ne dépense pas le budget des autres.
Residency : Stockez les messages et l'outbox dans la même région que les données de domaine ; les répliques interrégionales sont des agrégats asynchrones.

9) Observation et audit

Tracing : corrélation 'event _ id '/' aggregate _ id '/' saga _ id', spans 'read → process → write/commit'.
Métriques : publication/traitement (p95/p99), proportion de succès, taux DLQ, succès redrive, « doublons supprimés ».
Logs : bref succès ; en détail sur les erreurs (cause, tentative, clé, offset).
Audit : qui a redrayvé/reculé, quel batch et avec quel résultat.

10) Sécurité et conformité

Minimiser le PII dans payload ; masquer lors du transfert vers DLQ/logs.
Signer/chiffrer les messages pour les bus externes ; Utilisez mTLS entre les services.
Gérer la durée de conservation et le « droit à l'oubli » per tenant/region.

11) Schémas types d'intégration

1. Service source (write-side)

Transaction locale : enregistrement de domaine + outbox.
Pablisher : batchi, 'SKIP LOCKED', backoff, limites per tenant.
Surveillance de lag'now − occurred_at'.

2. Service-consommateur (read-side)

La lecture du batch → la tentative 'INSERT inbox (consumer, event_id)' → lorsque nous réussissons, nous produisons un effet.
Dans la même transaction, nous enregistrons un « offset passé » (option A) ou nous comptons sur une transaction de courtier (option B).
Sur l'erreur : rétrogradation ou DLQ sur la politique.

3. Projection/vue matérialisée

Seulement les apdates idempotent (upsert), les clés compactes du grand-père, le rapprochement périodique des montants de contrôle.

12) Modèles de configuration (exemple)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Chèque-liste avant la vente

• Élimination du « deux écritures » : outbox sur le revendeur ou fixation de l'offset et de l'effet en une seule transaction chez le consumer.
• Idempotent consumer : « inbox »/journal de dedup, idempotence commerciale des opérations.
• Partitionnement par clé d'affaires, ordre local respecté.
• Retraits avec backoff + gitter, classification des erreurs, DLQ avec des métadonnées riches.
• Redrive dosé, sans danger ; il y a des playbooks.
• Limites et priorités à tenants multiples ; les balises 'tenant _ id/plan/region'.
• Télémétrie : lags, proportion de succès, « doublons supprimés », alertes p95/p99.
• Les politiques PII/rétentions/cryptage ont été respectées.
• Tests : chute entre les étapes, doublons, ordre par clé, redrave de masse.

14) Erreurs typiques

Envoyer au bus et écrire dans la base de données par étapes séparées sans outbox/transaction offset.
Consumer sans idempotence → double les effets secondaires.
L'ordre mondial « à tout prix » est cher et rarement justifié ; l'ordre de la clé suffit.
Massif редрайв sans limites → l'incident secondaire.
Absence de tracing/lag-métrique → « dégradation latente ».
Mélange PII dans DLQ/logs.

15) Recettes rapides

Événements SaaS : Outbox + consumer idempotent (inbox), lot par 'tenant _ id : aggregate _ id'.
ETL/projections : Read-process-write avec fixation offset en une seule transaction, batchi 500-1000, upsert.
Charge élevée : Chardonnoir des pablishers, 'SKIP LOCKED', WFQ per tenant, contrôle de la lagune.
Une zone de conformité rigoureuse : outbox régionale, cryptage payload, rétention et audit redrave.

Conclusion

Le messagerie transactionnelle est une discipline de connexion de données et de messages. En combinant outbox/inbox, idempotence, fixation offset avec effets et retraits gérables avec DLQ, vous obtenez un comportement exactly-once pratique sans verrous globaux et conservez le SLO même en cas de pannes, de pics et d'exploitation complexe multi-tenants.