Architecture
Diagramme d'architecture outbox transactionnel où les écritures de domaine et la publication d'événements se font dans la même transaction de base de données, avec un processus relais interrogeant la table outbox et publiant les événements vers un broker de messages avec livraison garantie. Ce modèle résout le problème de double écriture où la mise à jour d'une base de données et la publication d'un événement ne sont pas atomiques, garantissant une livraison d'événements exactement une fois sans transactions distribuées. Critique pour les architectures événementielles nécessitant une publication de messages fiable.
Code FlowZap complet
Application { # Application Service
n1: circle label:"Business Operation"
n2: rectangle label:"Begin Transaction"
n3: rectangle label:"Update Domain Table"
n4: rectangle label:"Insert into Outbox Table"
n5: rectangle label:"Commit Transaction"
n6: circle label:"Return Success"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Atomic"]
n3.handle(right) -> n4.handle(left) [label="Same TX"]
n4.handle(right) -> n5.handle(left) [label="Commit"]
n5.handle(right) -> n6.handle(left)
n4.handle(bottom) -> Database.n7.handle(top) [label="Write"]
}
Database { # Database
n7: rectangle label:"Domain Table (Orders)"
n8: rectangle label:"Outbox Table (Events)"
n9: rectangle label:"Outbox Row: Pending"
n7.handle(right) -> n8.handle(left) [label="Same Database"]
n8.handle(right) -> n9.handle(left) [label="Status: PENDING"]
n9.handle(bottom) -> Relay.n10.handle(top) [label="Poll"]
}
Relay { # Outbox Relay (Debezium/Poller)
n10: rectangle label:"Poll Outbox Table"
n11: rectangle label:"Read Pending Events"
n12: rectangle label:"Publish to Message Broker"
n13: diamond label:"Published Successfully?"
n14: rectangle label:"Mark as Processed"
n15: rectangle label:"Retry with Backoff"
n10.handle(right) -> n11.handle(left) [label="SELECT WHERE status=PENDING"]
n11.handle(right) -> n12.handle(left) [label="Serialize"]
n12.handle(right) -> n13.handle(left)
n13.handle(right) -> n14.handle(left) [label="Yes"]
n13.handle(bottom) -> n15.handle(top) [label="No"]
n14.handle(top) -> Database.n9.handle(bottom) [label="UPDATE status=DONE"]
n15.handle(top) -> n12.handle(bottom) [label="Retry"]
}
Consumers { # Downstream Consumers
n16: rectangle label:"Notification Service"
n17: rectangle label:"Analytics Service"
n18: rectangle label:"Search Index Service"
n12.handle(bottom) -> Consumers.n16.handle(top) [label="OrderCreated"]
n12.handle(bottom) -> Consumers.n17.handle(top) [label="OrderCreated"]
n12.handle(bottom) -> Consumers.n18.handle(top) [label="OrderCreated"]
}
Pourquoi ce workflow ?
Publishing an event to a message broker after updating a database is a dual-write problem—if the broker publish fails after the database commit, the event is lost. The outbox pattern solves this by writing both the domain change and the event to the same database transaction, then reliably relaying events to the broker.
Comment ça fonctionne
- Step 1: The application begins a database transaction.
- Step 2: The domain table is updated with the business data change.
- Step 3: An event record is inserted into the outbox table within the same transaction.
- Step 4: The transaction commits atomically, guaranteeing both writes succeed or fail together.
- Step 5: A relay process (Debezium CDC or polling) reads pending outbox events.
- Step 6: Events are published to the message broker and marked as processed in the outbox table.
Alternatives
Application-level event publishing risks data inconsistency on partial failures. CDC without an outbox table captures all changes, not just domain events. This template shows the transactional outbox pattern for guaranteed event delivery.
Key Facts
| Template Name | Architecture du pattern Outbox pour messagerie fiable |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture Change Data Capture utilisant Debezium pour lire les journaux de transactions de la base de données et publier des événements de changement vers Kafka, alimentant des consommateurs en aval qui mettent à jour les index de recherche, invalident les caches, chargent les entrepôts de données et écrivent les journaux d'audit. Ce modèle montre comment le CDC élimine les problèmes de double écriture en capturant les changements au niveau de la base de données sans modifier le code applicatif. Critique pour la synchronisation de données entre systèmes hétérogènes.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.