Architecture
Une architecture IA agentique event-driven qui remplace l'orchestrateur central par des topics Kafka/PubSub : les agents s'abonnent, réagissent et publient de nouveaux événements. Cela aligne les systèmes multi-agents avec la chorégraphie microservices éprouvée et est idéale pour les systèmes temps réel, haut débit et les configurations 'maillage d'agents'.
Code FlowZap complet
Source { # Event Sources
n1: circle label:"Start"
n2: rectangle label:"User action event"
n3: rectangle label:"System alert event"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"]
n3.handle(bottom) -> Broker.n4.handle(top) [label="Publish event"]
}
Broker { # Event Broker (Kafka / Pub-Sub)
n4: rectangle label:"Event bus receives event"
n5: rectangle label:"Route to subscribers"
n4.handle(right) -> n5.handle(left)
n5.handle(bottom) -> Orders.n6.handle(top) [label="topic: orders"]
n5.handle(bottom) -> Alerts.n8.handle(top) [label="topic: alerts"]
n5.handle(bottom) -> Analytics.n10.handle(top) [label="topic: analytics"]
}
Orders { # Order Processing Agent
n6: rectangle label:"Parse order event"
n7: rectangle label:"Execute fulfillment"
n6.handle(right) -> n7.handle(left)
n7.handle(bottom) -> Broker.n4.handle(top) [label="Publish: order.completed"]
}
Alerts { # Alert Triage Agent
n8: rectangle label:"Classify severity"
n9: rectangle label:"Route to on-call or auto-resolve"
n8.handle(right) -> n9.handle(left)
n9.handle(bottom) -> Broker.n4.handle(top) [label="Publish: alert.resolved"]
}
Analytics { # Analytics Agent
n10: rectangle label:"Aggregate metrics"
n11: rectangle label:"Update dashboard"
n12: circle label:"Stored"
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left)
}
Modèles associés
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 événementielle publish-subscribe avec broker de messages Kafka ou RabbitMQ, sérialisation d'événements, partitionnement de topics, livraison fan-out vers plusieurs consommateurs et gestion des erreurs via file de lettres mortes. Ce modèle représente le pattern fondamental de messagerie asynchrone où producteurs et consommateurs sont entièrement découplés via un broker de messages. Essentiel pour les architectes construisant des systèmes événementiels faiblement couplés et évolutifs.
Architecture
Diagramme d'architecture de chorégraphie événementielle où les microservices se coordonnent par événements sans orchestrateur central, avec les services Commande, Paiement, Inventaire et Expédition réagissant aux événements de domaine les uns des autres. Ce modèle représente le pattern de coordination décentralisée où chaque service ne connaît que ses propres responsabilités et publie des événements pour que d'autres les consomment. Idéal pour les équipes favorisant l'autonomie des services plutôt que le contrôle centralisé des workflows.
Architecture
Une architecture IA agentique à agent unique où un seul agent gère tout : analyser les requêtes, raisonner, appeler les outils via MCP, et générer les réponses. C'est l'architecture par défaut pour les prototypes et automatisations simples—facile à déboguer mais atteint rapidement les limites de fenêtre de contexte et est difficile à paralléliser. Idéale pour les MVPs et les développeurs solo qui livrent vite.
Architecture
Une architecture pipeline séquentiel enchaînant plusieurs agents dans un ordre fixe (analyser → enrichir → analyser → formater), ce qui est une configuration 'microservices LLM' courante quand chaque étape peut être isolée. Cette structure est souvent utilisée dans le traitement de documents et les workflows de type ETL car chaque étape est testable et prévisible.
Architecture
Une architecture orchestrateur-travailleur où un agent orchestrateur décompose un objectif en sous-tâches, les distribue à des travailleurs spécialisés, puis synthétise une réponse finale. C'est l'architecture 'orchestration d'agents' la plus courante—puissante mais l'orchestrateur peut devenir un goulot d'étranglement à mesure que le nombre de travailleurs augmente.