Bienvenue sur FlowZap, l'application pour créer des diagrammes avec Rapidité, Clarté et Contrôle.

Modèles de diagrammes d'architecture

Explorez 50 modèles de diagrammes d'architecture couvrant les Microservices, l'Event-Driven, le CQRS, le Serverless, le pattern Saga, le Circuit Breaker, le Bulkhead, l'architecture hexagonale, la Clean Architecture, le Domain-Driven Design et bien plus. Chaque modèle est un diagramme FlowZap Code prêt pour la production, téléchargeable en fichier .fz et personnalisable dans l'éditeur FlowZap.

Microservices

Architecture de passerelle API pour microservices

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.

Nœuds: 17Lanes: 3Complexité: ★★★★
Voir le modèle

Architecture de maillage de services pour microservices

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é.

Nœuds: 18Lanes: 3Complexité: ★★★★
Voir le modèle

Architecture base de données par service pour microservices

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.

Nœuds: 16Lanes: 4Complexité: ★★★★
Voir le modèle

Décomposition de microservices par capacité métier

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.

Nœuds: 17Lanes: 5Complexité: ★★★★
Voir le modèle

Architecture de migration Strangler Fig pour microservices

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.

Nœuds: 16Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture de découverte de services pour microservices

Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.

Nœuds: 16Lanes: 3Complexité: ★★★
Voir le modèle

Architecture du pattern Sidecar pour microservices

Diagramme d'architecture du pattern sidecar montrant le proxy Envoy, le collecteur de logs et le watcher de configuration fonctionnant aux côtés des conteneurs applicatifs dans un pod Kubernetes, avec un plan de contrôle gérant la configuration. Ce modèle démontre comment les préoccupations auxiliaires comme la journalisation, la surveillance et la configuration sont déployées en tant que conteneurs co-localisés. Fondamental pour les équipes adoptant des patterns d'orchestration de conteneurs cloud-native.

Nœuds: 13Lanes: 3Complexité: ★★★★
Voir le modèle

Architecture Backend-for-Frontend (BFF) pour microservices

Diagramme d'architecture Backend-for-Frontend avec des couches BFF séparées pour les clients web et mobile, chacune optimisant les réponses API pour sa plateforme spécifique tout en partageant des microservices backend communs. Ce modèle montre comment éviter les API universelles en adaptant l'agrégation des données et l'optimisation des charges utiles par type de client. Recommandé pour les équipes servant plusieurs plateformes frontend depuis un backend microservices partagé.

Nœuds: 12Lanes: 3Complexité: ★★★
Voir le modèle

Événementiel

Architecture événementielle Publish-Subscribe

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.

Nœuds: 17Lanes: 3Complexité: ★★★★
Voir le modèle

Architecture événementielle Event Sourcing

Diagramme d'architecture event sourcing où tous les changements d'état sont stockés comme une séquence immuable d'événements de domaine, avec des projections de lecture construites à partir du flux d'événements et une optimisation par snapshots pour un chargement rapide des agrégats. Ce modèle montre comment l'event sourcing élimine la perte de données en préservant l'historique complet de chaque transition d'état. Critique pour les systèmes nécessitant des pistes d'audit complètes, des requêtes temporelles et des capacités de rejeu d'événements.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture CQRS événementielle avec Event Store

Diagramme d'architecture CQRS combinant des API de commande et de requête séparées avec un bus d'événements pour la synchronisation asynchrone du modèle de lecture, incluant des projecteurs qui construisent des vues dénormalisées à partir des événements de domaine. Ce modèle démontre la pile complète CQRS+ES où les écritures passent par la validation du domaine et les lectures sont servies depuis des vues matérialisées optimisées. Idéal pour les systèmes à haut débit où les charges de lecture et d'écriture ont des exigences de mise à l'échelle fondamentalement différentes.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture événementielle par chorégraphie

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.

Nœuds: 19Lanes: 5Complexité: ★★★★
Voir le modèle

Architecture de pipeline de streaming événementiel

Diagramme d'architecture de pipeline de streaming temps réel avec capteurs IoT, logs applicatifs et données de parcours utilisateur transitant par Kafka vers Apache Flink pour l'agrégation par fenêtre, la détection d'anomalies et la sortie multi-destinations vers des lacs de données et des tableaux de bord. Ce modèle visualise le traitement de flux de bout en bout, de l'ingestion à la transformation, au stockage et à l'alerte. Essentiel pour les ingénieurs data construisant des plateformes d'analyse et de surveillance en temps réel.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture d'événements de domaine

Diagramme d'architecture d'événements de domaine montrant comment les racines d'agrégat émettent des événements de domaine qui sont distribués à la fois en interne aux gestionnaires locaux et en externe aux consommateurs d'événements d'intégration dans d'autres contextes bornés. Ce modèle représente le pattern d'événements DDD où la logique de domaine déclenche des effets de bord via un dispatcher d'événements propre, maintenant la séparation entre les préoccupations de domaine et d'infrastructure. Clé pour les équipes implémentant le Domain-Driven Design avec intégration événementielle.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture CDC (Change Data Capture) événementielle

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.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture de file de lettres mortes événementielle

Diagramme d'architecture de file de lettres mortes avec politiques de retry, backoff exponentiel, seuils de tentatives maximales, routage DLQ pour les messages échoués, alertes opérationnelles et workflows de retraitement manuel. Ce modèle représente le pattern critique de gestion des erreurs pour les systèmes de messagerie asynchrone, garantissant qu'aucun message n'est silencieusement perdu lors d'un échec de traitement. Essentiel pour construire des systèmes événementiels fiables avec des mécanismes de récupération appropriés.

Nœuds: 16Lanes: 3Complexité: ★★★
Voir le modèle

Architecture de hub de notifications événementiel

Diagramme d'architecture de hub de notifications événementiel avec ingestion d'événements multi-sources, rendu de messages basé sur des templates, routage par préférences utilisateur vers les canaux email (SendGrid/SES), push (FCM), SMS (Twilio) et Slack, avec suivi de livraison et mécanismes de retry. Ce modèle représente un système de notifications centralisé qui découple les services métier de l'infrastructure de livraison, supportant la communication multicanal avec des préférences contrôlées par l'utilisateur. Idéal pour les équipes plateforme construisant une infrastructure de notifications évolutive.

Nœuds: 20Lanes: 3Complexité: ★★★★
Voir le modèle

CQRS

Architecture CQRS de séparation lecture-écriture

Diagramme d'architecture CQRS de séparation lecture-écriture avec des chemins de commande et de requête dédiés, PostgreSQL pour les écritures, Redis ou Elasticsearch pour les lectures optimisées, et une couche de synchronisation événementielle avec surveillance du décalage. Ce modèle démontre le principe fondamental du CQRS de séparer les modèles de lecture et d'écriture pour mettre à l'échelle et optimiser chaque chemin indépendamment. Idéal pour les applications avec des ratios lecture/écriture asymétriques où la performance des requêtes est critique.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture CQRS de vues matérialisées

Diagramme d'architecture CQRS de vues matérialisées avec plusieurs projecteurs construisant des modèles de lecture spécifiques : résumés de commandes, tableaux de bord clients, cubes analytiques et index de recherche, tous alimentés par un flux d'événements unique. Ce modèle montre comment créer plusieurs vues de requête optimisées à partir des mêmes événements d'écriture, chacune adaptée à un cas d'usage spécifique avec une latence de lecture inférieure à la milliseconde. Parfait pour les systèmes nécessitant des patterns de requête diversifiés à partir d'une source de données unique.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture CQRS d'interface utilisateur basée sur les tâches

Diagramme d'architecture CQRS d'interface basée sur les tâches où le frontend capture l'intention de l'utilisateur sous forme de commandes explicites, les soumet de manière asynchrone avec des mises à jour optimistes, et reçoit des confirmations en temps réel via WebSocket lorsque le modèle de lecture est synchronisé. Ce modèle représente le pattern d'interface moderne qui remplace les formulaires CRUD par des commandes orientées intention, permettant des expériences utilisateur réactives avec cohérence à terme. Recommandé pour les équipes construisant des frontends réactifs sur des backends CQRS.

Nœuds: 19Lanes: 4Complexité: ★★★★
Voir le modèle

Serverless

Architecture backend API serverless

Diagramme d'architecture backend API serverless avec API Gateway, fonctions Lambda d'autorisation, fonctions de logique métier et services cloud managés incluant DynamoDB, S3, SQS et SNS pour un backend entièrement managé et auto-scalable. Ce modèle représente l'approche serverless-first où la gestion de l'infrastructure est entièrement éliminée, avec une tarification à l'invocation et une mise à l'échelle automatique jusqu'à zéro. Essentiel pour les startups et les équipes construisant des backends API événementiels économiques.

Nœuds: 15Lanes: 3Complexité: ★★★
Voir le modèle

Architecture de traitement d'événements serverless

Diagramme d'architecture de traitement d'événements serverless avec déclencheurs S3, DynamoDB Streams, API Gateway et CloudWatch invoquant des fonctions Lambda, orchestrées par Step Functions avec fan-out via SQS et gestion des erreurs par file de lettres mortes. Ce modèle montre comment construire des pipelines de traitement d'événements complexes entièrement à partir de composants serverless managés, sans serveurs à provisionner ou gérer. Idéal pour les workflows de traitement de données nécessitant une mise à l'échelle élastique et une tolérance aux pannes intégrée.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture d'orchestration Step Functions serverless

Diagramme d'architecture d'orchestration AWS Step Functions avec des workflows de machine à états incluant des états de choix, du traitement parallèle, des patterns d'attente de callback et un rollback de compensation pour les étapes échouées. Ce modèle représente l'orchestration de workflows serverless où des processus multi-étapes complexes sont définis comme des machines à états avec gestion des erreurs et logique de retry intégrées. Critique pour les équipes construisant des workflows serverless fiables nécessitant une approbation humaine ou des processus de longue durée.

Nœuds: 17Lanes: 3Complexité: ★★★★
Voir le modèle

Architecture de calcul en périphérie serverless

Diagramme d'architecture de calcul en périphérie serverless avec emplacements CloudFront ou Cloudflare, fonctions Lambda@Edge pour les tests A/B et la personnalisation géographique, regroupement de requêtes par origin shield et stratégies de réponse cache-first. Ce modèle visualise comment le calcul se déplace vers la périphérie du réseau pour des réponses à ultra-faible latence, avec des fonctions edge modifiant les requêtes et réponses avant qu'elles n'atteignent l'origine. Essentiel pour les applications critiques en performance servant un public mondial.

Nœuds: 15Lanes: 3Complexité: ★★★
Voir le modèle

Architecture de pipeline de données serverless

Diagramme d'architecture de pipeline de données serverless avec ingestion Kinesis, fonctions de transformation Lambda, zones de stockage S3 data lake (brute et curatée), enregistrement au catalogue Glue et moteur de requêtes Athena alimentant des tableaux de bord QuickSight et des modèles ML SageMaker. Ce modèle représente un pipeline ETL serverless complet de l'ingestion à la transformation, au catalogage et à l'analyse sans gérer d'infrastructure. Idéal pour les équipes data construisant des plateformes analytiques économiques.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture serverless multi-cloud

Diagramme d'architecture serverless multi-cloud avec routage du trafic basé sur le DNS entre les régions AWS et Azure, basculement automatique sur échec de vérification de santé et réplication bidirectionnelle des données avec résolution de conflits entre fournisseurs cloud. Ce modèle représente la stratégie multi-cloud pour une disponibilité maximale et une indépendance vis-à-vis des fournisseurs, utilisant des services serverless d'AWS (Lambda, DynamoDB) et d'Azure (Functions, Cosmos DB). Critique pour les entreprises nécessitant une redondance de fournisseur cloud.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Pattern Saga

Architecture du pattern Saga par orchestration

Diagramme d'architecture saga par orchestration avec un orchestrateur central coordonnant des transactions distribuées multi-étapes à travers les services Commande, Inventaire et Paiement, avec une chaîne de compensation dédiée pour le rollback en cas d'échec. Ce modèle représente le pattern saga basé sur l'orchestration où un coordinateur unique gère le cycle de vie de la transaction et déclenche des actions compensatoires lorsqu'une étape échoue. Essentiel pour les architectes implémentant des transactions distribuées fiables sans commit en deux phases.

Nœuds: 19Lanes: 5Complexité: ★★★★
Voir le modèle

Architecture du pattern Saga par chorégraphie

Diagramme d'architecture saga par chorégraphie où les services Commande, Paiement et Inventaire se coordonnent par événements de domaine sans orchestrateur central, chaque service publiant et s'abonnant à des événements qui font avancer la transaction ou déclenchent la compensation. Ce modèle représente l'approche saga décentralisée où les services réagissent de manière autonome aux événements, réduisant les points de défaillance uniques au prix d'une complexité accrue dans le suivi de l'état de la saga. Idéal pour les équipes préférant l'autonomie des services au contrôle centralisé.

Nœuds: 18Lanes: 5Complexité: ★★★★
Voir le modèle

Architecture de transaction distribuée Saga

Diagramme d'architecture de transaction distribuée implémentant le protocole de commit en deux phases avec un coordinateur de transaction envoyant des messages de préparation et de commit aux services participants, avec un abandon global en cas d'échec de vote. Ce modèle visualise le protocole 2PC classique utilisé lorsqu'une cohérence forte est requise entre plusieurs services, montrant les phases de préparation, vote et commit/abandon. Important pour comprendre les compromis de consensus distribué dans les architectures microservices.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture Saga de réservation de voyage

Diagramme d'architecture saga de réservation de voyage orchestrant les réservations de vol, d'hôtel et de location de voiture comme une seule transaction distribuée, avec compensation automatique pour annuler toutes les réservations si une étape échoue. Ce modèle représente le cas d'usage classique de saga où plusieurs services indépendants doivent tous réussir ou tous annuler, garantissant que les voyageurs ne se retrouvent jamais avec des réservations partielles. Parfait pour démontrer les patterns saga avec un scénario métier réel.

Nœuds: 17Lanes: 5Complexité: ★★★★
Voir le modèle

Architecture Saga d'exécution de commande

Diagramme d'architecture saga d'exécution de commande avec quatre étapes séquentielles : vérification du client, réservation d'inventaire, autorisation de paiement et création d'expédition, avec une chaîne de compensation qui inverse les étapes complétées en cas d'échec. Ce modèle représente le cycle de vie complet de la commande sous forme de saga, montrant comment chaque service participe à la transaction et comment les actions compensatoires maintiennent la cohérence des données. Idéal pour les architectes e-commerce concevant des pipelines de traitement de commandes fiables.

Nœuds: 18Lanes: 3Complexité: ★★★★
Voir le modèle

Résilience

Architecture de résilience par disjoncteur

Diagramme d'architecture de résilience par disjoncteur montrant la machine à états complète avec les états fermé, ouvert et semi-ouvert, le suivi du seuil de défaillance, le timer de récupération et les stratégies de réponse de repli pour protéger les services des défaillances en cascade. Ce modèle visualise le pattern disjoncteur en détail, incluant comment le disjoncteur transite entre les états en fonction des compteurs de succès et d'échec. Essentiel pour construire des microservices tolérants aux pannes qui se dégradent gracieusement sous charge.

Nœuds: 18Lanes: 3Complexité: ★★★★
Voir le modèle

Architecture d'isolation par cloison (Bulkhead)

Diagramme d'architecture d'isolation par cloison avec des pools de threads séparés pour les charges de travail critiques, standard et batch, chacun avec des pools de connexions indépendants, une détection d'épuisement et des stratégies de contre-pression pour empêcher une charge de travail d'affamer les autres. Ce modèle représente le pattern bulkhead inspiré des compartiments de coque de navire, où l'isolation des ressources garantit qu'une défaillance ou surcharge dans un composant ne peut pas se propager aux autres. Critique pour les systèmes nécessitant une disponibilité garantie pour les opérations hautement prioritaires.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture de retry avec backoff exponentiel

Diagramme d'architecture de retry avec backoff exponentiel montrant le moteur complet de politique de retry avec classification des erreurs retryables vs non-retryables, calcul de délai exponentiel avec jitter, seuils de tentatives maximales et gestion gracieuse de l'épuisement. Ce modèle représente le pattern de résilience essentiel pour gérer les défaillances transitoires dans les systèmes distribués, prévenant les problèmes de thundering herd par des délais de backoff aléatoires. Fondamental pour toute communication inter-services dans les architectures cloud.

Nœuds: 17Lanes: 3Complexité: ★★★
Voir le modèle

Architecture de limiteur de débit

Diagramme d'architecture de limiteur de débit implémentant l'algorithme token bucket avec compteurs distribués Redis, journaux de fenêtre glissante, identification par clé API, en-têtes de limite de débit et synchronisation multi-nœuds pour une application cohérente. Ce modèle montre comment protéger les API contre les abus et assurer une utilisation équitable entre les clients, avec des réponses HTTP 429 appropriées et des en-têtes Retry-After. Essentiel pour les équipes plateforme API construisant une infrastructure de limitation de débit de production.

Nœuds: 17Lanes: 4Complexité: ★★★
Voir le modèle

Architecture du pattern de vérification de santé

Diagramme d'architecture du pattern de vérification de santé avec sondes de load balancer, vérifications de santé approfondies vérifiant la base de données, le cache, le disque et l'état des dépendances, rotation automatique des instances et intégration d'alertes avec PagerDuty pour les échecs consécutifs. Ce modèle représente l'infrastructure de surveillance de santé qui permet des systèmes auto-réparateurs, où les instances défaillantes sont automatiquement retirées de la rotation et les équipes opérationnelles sont alertées. Clé pour construire des services prêts pour la production avec une observabilité appropriée.

Nœuds: 19Lanes: 4Complexité: ★★★
Voir le modèle

Patterns de conception

Architecture hexagonale (Ports et Adaptateurs)

Diagramme d'architecture hexagonale montrant la séparation nette entre le cœur de domaine, les adaptateurs entrants (REST, GraphQL, CLI, consommateurs de messages), les adaptateurs sortants (PostgreSQL, Stripe, email, Redis) et les interfaces de ports qui les connectent. Ce modèle visualise le pattern ports et adaptateurs où le cœur de domaine n'a aucune dépendance sur l'infrastructure, le rendant entièrement testable et agnostique technologiquement. Fondamental pour les équipes adoptant les principes d'architecture propre dans leur base de code.

Nœuds: 16Lanes: 4Complexité: ★★★★
Voir le modèle

Couches d'architecture propre (Clean Architecture)

Diagramme des couches d'architecture propre montrant les quatre couches concentriques : Entités (domaine), Cas d'utilisation (application), Adaptateurs d'interface (contrôleurs, présentateurs, repositories) et Frameworks & Drivers (serveur web, base de données, SDK cloud). Ce modèle représente la Clean Architecture d'Uncle Bob avec la règle de dépendance où les couches internes ne dépendent jamais des couches externes, garantissant que le modèle de domaine reste pur et indépendant du framework. Référence essentielle pour les architectes logiciels imposant des frontières architecturales.

Nœuds: 16Lanes: 4Complexité: ★★★
Voir le modèle

Architecture DDD des contextes bornés

Diagramme d'architecture DDD des contextes bornés avec les contextes Commande, Client, Expédition et Facturation connectés via une couche anti-corruption, un noyau partagé et une carte de contextes définissant les relations d'intégration. Ce modèle visualise les patterns stratégiques DDD pour décomposer des domaines complexes en contextes bornés autonomes qui communiquent par des événements d'intégration bien définis. Critique pour les architectes appliquant le Domain-Driven Design aux systèmes d'entreprise à grande échelle.

Nœuds: 18Lanes: 5Complexité: ★★★★
Voir le modèle

Architecture du pattern de composition d'API

Diagramme d'architecture de composition d'API avec un service compositeur qui distribue des requêtes parallèles vers plusieurs microservices, collecte les réponses avec gestion de timeout et fusionne les résultats en une réponse unifiée unique avec support de repli partiel. Ce modèle représente le pattern de composition d'API utilisé lorsqu'une requête client unique nécessite des données de plusieurs services, évitant les appels directs de service à service. Utile pour les équipes construisant des couches d'agrégation dans les architectures microservices.

Nœuds: 16Lanes: 3Complexité: ★★★
Voir le modèle

Architecture du pattern Outbox pour messagerie fiable

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.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture du pattern Ambassador

Diagramme d'architecture du pattern ambassador avec un proxy sidecar local gérant l'injection d'en-têtes d'authentification, le disjoncteur, la logique de retry et la collecte de métriques pour les requêtes sortantes vers des API tierces externes. Ce modèle représente le pattern ambassador où un service auxiliaire fonctionnant aux côtés de l'application décharge les préoccupations transversales pour la communication externe. Utile pour les équipes s'intégrant avec des services tiers peu fiables nécessitant des wrappers de résilience.

Nœuds: 15Lanes: 3Complexité: ★★★
Voir le modèle

Avancé

Architecture de fédération GraphQL

Diagramme d'architecture de fédération GraphQL avec une passerelle Apollo construisant des plans de requête et distribuant vers les sous-graphes Utilisateur, Produit et Avis, chacun possédant son schéma et sa base de données, avec assemblage des réponses en un résultat GraphQL unifié. Ce modèle représente l'approche GraphQL fédérée où plusieurs équipes développent et déploient indépendamment leurs sous-graphes tandis que les clients voient une API unifiée unique. Idéal pour les organisations mettant à l'échelle GraphQL à travers plusieurs équipes et services.

Nœuds: 15Lanes: 3Complexité: ★★★
Voir le modèle

Architecture de sécurité Zero Trust

Diagramme d'architecture de sécurité zero trust avec vérifications de posture des appareils, vérification d'identité MFA, décisions de politique basées sur le risque, jetons JWT à courte durée de vie, micro-segmentation, chiffrement mTLS, application du moindre privilège et surveillance continue. Ce modèle représente le paradigme de sécurité « ne jamais faire confiance, toujours vérifier » où chaque requête est authentifiée et autorisée indépendamment de l'emplacement réseau. Essentiel pour les architectes sécurité implémentant des frameworks zero-trust modernes dans des environnements cloud-native.

Nœuds: 19Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture SaaS multi-tenant

Diagramme d'architecture SaaS multi-tenant avec identification du tenant, routage basé sur le niveau (pools partagés vs dédiés), sécurité au niveau des lignes, clés de chiffrement par tenant et stratégies de sauvegarde isolées pour les modèles d'isolation standard et entreprise. Ce modèle représente les décisions architecturales pour construire des plateformes SaaS servant plusieurs clients depuis une infrastructure partagée tout en maintenant une isolation stricte des données. Critique pour les architectes SaaS équilibrant l'efficacité des coûts avec les exigences de sécurité entreprise.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture d'orchestration de conteneurs Kubernetes

Diagramme d'architecture d'orchestration de conteneurs Kubernetes montrant le plan de contrôle (API Server, etcd, Scheduler, Controller Manager), les nœuds worker (Kubelet, runtime de conteneurs, kube-proxy, pods), la couche réseau (Ingress, Network Policy, Service Mesh) et le stockage persistant avec pilotes CSI. Ce modèle fournit une vue complète de la pile architecturale Kubernetes du plan de contrôle à la couche de stockage. Référence fondamentale pour les ingénieurs DevOps et les équipes plateforme gérant des clusters Kubernetes.

Nœuds: 18Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture Data Mesh

Diagramme d'architecture data mesh avec propriété des données orientée domaine à travers les domaines Ventes, Marketing et Finance, chacun exposant des produits de données en libre-service via des API avec des SLA de qualité, gouvernés par une plateforme de données fédérée avec un catalogue partagé et un moteur de requêtes inter-domaines. Ce modèle représente le changement de paradigme des équipes data centralisées vers des produits de données possédés par les domaines, appliquant les principes des microservices à l'architecture de données. Essentiel pour les organisations mettant à l'échelle les opérations data au-delà des goulots d'étranglement des entrepôts de données centralisés.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture cellulaire (Cell-Based)

Diagramme d'architecture cellulaire avec routage géographique vers des cellules indépendantes et autonomes (US-East, EU-West), chacune avec sa propre passerelle, calcul, base de données, cache et file de messages, plus des services partagés pour la réplication inter-cellules et la configuration globale. Ce modèle représente le pattern d'architecture cellulaire utilisé par les systèmes hyperscale pour atteindre l'isolation du rayon d'impact, où les défaillances dans une cellule ne peuvent pas affecter les utilisateurs d'une autre. Clé pour les architectes concevant des systèmes nécessitant une disponibilité extrême et une isolation des pannes.

Nœuds: 20Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture d'observabilité des trois piliers

Diagramme d'architecture d'observabilité implémentant les trois piliers (métriques, traces, logs) avec instrumentation SDK OpenTelemetry, pipeline de collecteur OTLP, backends Prometheus, Jaeger et Loki, tableaux de bord Grafana, suivi SLO/SLI et intégration d'alertes PagerDuty. Ce modèle fournit une référence complète de pile d'observabilité montrant comment les données de télémétrie circulent de l'instrumentation applicative à la collecte, au stockage, à la visualisation et à la réponse aux incidents. Essentiel pour les équipes SRE construisant une infrastructure de surveillance de production.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture de déploiement GitOps

Diagramme d'architecture de déploiement GitOps avec workflow Git développeur, pipeline CI/CD construisant et poussant des images de conteneurs, ArgoCD ou Flux détectant les changements de manifestes Git, détection de dérive, synchronisation automatique du cluster et déploiement par mise à jour progressive vers Kubernetes. Ce modèle représente le paradigme GitOps où Git est la source unique de vérité pour le code applicatif et l'état de l'infrastructure, permettant des déploiements déclaratifs, auditables et reproductibles. Critique pour les équipes adoptant les pratiques GitOps pour les déploiements Kubernetes.

Nœuds: 19Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture IA-Native Agent Unique

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.

Nœuds: 11Lanes: 3Complexité: ★★
Voir le modèle

Architecture IA-Native Pipeline Séquentiel

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.

Nœuds: 7Lanes: 2Complexité: ★★
Voir le modèle

Architecture IA-Native Orchestrateur-Travailleur

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.

Nœuds: 14Lanes: 4Complexité: ★★★
Voir le modèle

Architecture IA-Native Hiérarchique

Une architecture multi-agents hiérarchique qui scalde l'orchestration en empilant superviseurs et chefs d'équipe (une structure arborescente), ce qui reflète les structures organisationnelles d'entreprise et aide à partitionner le contexte. C'est l'architecture 'IA agentique de niveau entreprise' quand un seul orchestrateur ne peut pas gérer tous les travailleurs directement.

Nœuds: 16Lanes: 4Complexité: ★★★★
Voir le modèle

Architecture IA-Native Fan-Out Parallèle

Une architecture fan-out parallèle qui exécute plusieurs agents simultanément sur des vérifications indépendantes (style, sécurité, performance) puis fusionne les résultats. C'est une approche standard de conception multi-agents pour le débit, s'appliquant bien au CI/CD, à la réponse aux incidents et à la recherche.

Nœuds: 11Lanes: 2Complexité: ★★★
Voir le modèle

Architecture IA-Native Event-Driven Kafka

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'.

Nœuds: 12Lanes: 5Complexité: ★★★
Voir le modèle

Architecture IA-Native Générateur-Critique

Une architecture compétitive / générateur-critique où plusieurs générateurs produisent des réponses indépendantes, puis un agent évaluateur note et sélectionne la meilleure sortie. Cette approche améliore la qualité et réduit la fragilité d'un modèle unique. C'est plus coûteux (plusieurs appels LLM) mais rentable quand la correction ou la créativité compte plus que la latence.

Nœuds: 9Lanes: 3Complexité: ★★★
Voir le modèle

Architecture Agentique Superviseur-Travailleur

Une architecture multi-agents superviseur-travailleur où un agent orchestrateur reçoit un objectif de haut niveau, le décompose en sous-tâches, délègue chacune à des agents travailleurs spécialisés (chercheur, rédacteur, QA), surveille l'exécution, gère les échecs et synthétise les résultats. L'orchestrateur gère mais n'exécute pas les tâches lui-même.

Nœuds: 10Lanes: 4Complexité: ★★★
Voir le modèle

Architecture Pipeline Séquentiel Agentique

Une architecture multi-agents pipeline séquentiel où les agents sont arrangés dans une séquence stricte. Chaque agent transforme ou enrichit la sortie du précédent, puis la passe au suivant. Pas d'orchestrateur central — le flux est déterministe comme une chaîne d'assemblage.

Nœuds: 5Lanes: 5Complexité: ★★
Voir le modèle

Architecture Essaim Agentique

Une architecture multi-agents essaim où plusieurs agents travaillent simultanément sur les mêmes tâches ou des tâches connexes, sans coordinateur central. Leurs sorties sont ensuite agrégées, votées ou fusionnées par un nœud agrégateur dédié. Les agents peuvent rivaliser — la meilleure sortie gagne.

Nœuds: 6Lanes: 5Complexité: ★★★
Voir le modèle

Architecture Hiérarchique Agentique

Une architecture multi-agents hiérarchique avec structure organisationnelle multi-niveaux. Un agent exécutif de niveau supérieur gère des agents chefs d'équipe de niveau intermédiaire, qui gèrent chacun leur propre pool de travailleurs spécialisés. Des équipes dans les équipes — la hiérarchie correspond à la séparation des domaines.

Nœuds: 8Lanes: 7Complexité: ★★★★
Voir le modèle

Architecture Équipe de Rivaux Agentique

Le pattern multi-agents le plus sophistiqué architecturalement. Les agents se voient assigner non seulement des rôles mais des incitations opposées. Un Planificateur est optimiste sur l'accomplissement de l'objectif. Un Critique est constitutionnellement sceptique et détient l'autorité de veto. Les erreurs sont détectées par pression contradictoire plutôt qu'en faisant confiance à l'auto-évaluation d'un seul modèle.

Nœuds: 5Lanes: 3Complexité: ★★★
Voir le modèle

Orchestration IA - Agent Unique (Monolithe)

L'architecture IA-native la plus simple — un agent unique qui reçoit l'entrée utilisateur, raisonne, planifie, décide des appels d'outils, traite les résultats et génère des réponses. Connexion MCP directe via stdio ou HTTP. Idéal pour les MVP et quand la latence faible compte.

Nœuds: 12Lanes: 3Complexité: ★★
Voir le modèle

Orchestration IA - Pipeline Séquentiel

Une architecture chaîne d'assemblage où les agents sont arrangés dans une séquence stricte. Chaque agent transforme ou enrichit la sortie du précédent, puis la passe au suivant. Idéal pour les tâches avec dépendances séquentielles claires — traitement de documents, pipelines de production de contenu, workflows de conformité.

Nœuds: 5Lanes: 2Complexité: ★★
Voir le modèle

Orchestration IA - Orchestrateur-Travailleur

Une architecture style conducteur où un agent orchestrateur reçoit une tâche complexe, la décompose en sous-tâches, délègue chacune à des agents travailleurs spécialisés (recherche, code, revue), collecte les résultats et synthétise la réponse finale. Idéal pour les tâches multi-étapes complexes avec décomposition dynamique.

Nœuds: 15Lanes: 5Complexité: ★★★
Voir le modèle

Orchestration IA - Hiérarchique (Organigramme)

Une architecture organigramme avec structure multi-niveaux. Un superviseur de niveau supérieur gère des chefs d'équipe, qui gèrent chacun leur propre pool de travailleurs spécialisés. Des équipes dans les équipes. Idéal pour l'automatisation à échelle entreprise avec 10+ agents spécialisés couvrant plusieurs domaines.

Nœuds: 17Lanes: 5Complexité: ★★★★
Voir le modèle

Orchestration IA - Fan-Out Parallèle (Map-Reduce)

Une architecture style map-reduce où un coordinateur distribue les tâches à plusieurs agents travailleurs parallèles (vérification style, audit sécurité, analyse performance), rassemble tous les résultats et prend une décision agrégée. Idéal pour les revues de PR, revues de code et analyse multi-dimensionnelle.

Nœuds: 9Lanes: 3Complexité: ★★★
Voir le modèle

Orchestration IA - Maillage Event-Driven (Kafka-First)

Une architecture maillage d'agents event-driven utilisant un broker d'événements style Kafka. Plusieurs agents s'abonnent à des topics (commandes, alertes, analytique), traitent les événements indépendamment, et publient les résultats sur le bus. Idéal pour le traitement d'événements temps réel et architectures de services découplés.

Nœuds: 13Lanes: 5Complexité: ★★★
Voir le modèle

Orchestration IA - Générateur-Critique Compétitif

Une architecture mode tournoi où plusieurs agents générateurs produisent des sorties indépendantes en parallèle, puis un agent évaluateur note et sélectionne la meilleure. Vérification de seuil de qualité avec boucles de raffinement. Idéal quand la correction ou créativité compte plus que la latence.

Nœuds: 10Lanes: 3Complexité: ★★★
Voir le modèle

Gestion de Contexte - Mémoire de Session

Pattern de contexte court terme où le canal envoie les nouveaux messages plus l'historique récent. Le runtime agent fusionne cela avec l'état de session local, assemble l'invite, et persiste la réponse dans l'historique. Simple mais le coût et la latence augmentent avec la longueur de l'historique.

Nœuds: 9Lanes: 3Complexité: ★★
Voir le modèle

Gestion de Contexte - Mémoire Résumée Progressive

Pattern d'historique compressé qui garde l'historique complet pendant un moment, puis quand un seuil est atteint, résume le dernier morceau et remplace les tours détaillés par un message résumé plus court. Réduit dramatiquement la taille de l'invite sur les conversations longues tout en maintenant la continuité de l'essentiel.

Nœuds: 8Lanes: 4Complexité: ★★★
Voir le modèle

Gestion de Contexte - Mémoire de Profil

Pattern de mémoire style identité où les données de profil sont chargées au démarrage de session. Chaque invite combine le persona système, le profil utilisateur, et le message courant. Les nouveaux faits peuvent être écrits dans la mémoire de profil. Surcharge prévisible minimale avec grande amélioration UX — l'agent se souvient de votre nom, stack, ton et contraintes.

Nœuds: 7Lanes: 3Complexité: ★★
Voir le modèle

Gestion de Contexte - Mémoire Sémantique

Pattern de mémoire basé sur vecteurs où le texte est découpé, embeddé et stocké dans une base de données vectorielle. À la requête, la question est embeddée, une recherche vectorielle est exécutée, les candidats sont re-classés, et les meilleurs résultats sont injectés dans l'invite. Là où l'agent donne l'impression de tout se souvenir sans halluciner.

Nœuds: 9Lanes: 4Complexité: ★★★
Voir le modèle

Gestion de Contexte - Mémoire Épisodique

Pattern d'apprentissage par l'expérience où chaque exécution de tâche devient un épisode avec entrée, actions et résultat. Avant d'aborder une nouvelle tâche, l'agent récupère des épisodes similaires et les utilise comme indices. Avec le temps, l'agent donne l'impression d'apprendre au lieu de répéter les mêmes plans échoués.

Nœuds: 11Lanes: 4Complexité: ★★★
Voir le modèle

Gestion de Contexte - Mémoire Récupération Hybride

Pattern de récupération multi-modal combinant recherche sémantique, recherche exacte/mots-clés, et recherche par récence en parallèle. Les résultats sont fusionnés et re-classés en un seul ensemble de contexte. Rappel beaucoup plus élevé car l'agent peut trouver à la fois des références floues et des entités exactes. Essentiel pour la récupération de connaissances complète.

Nœuds: 11Lanes: 5Complexité: ★★★★
Voir le modèle

Gestion de Contexte - Mémoire Partagée

Pattern de coordination multi-agents où un orchestrateur décompose le travail en sous-tâches, les agents spécialistes tirent de et poussent vers un store d'état partagé, et l'orchestrateur compose la réponse finale depuis cet état partagé. Les configurations multi-agents semblent cohérentes au lieu que chaque assistant ait sa propre mémoire inconsistante.

Nœuds: 9Lanes: 4Complexité: ★★★
Voir le modèle

Architecture du harnais Claw Code

Diagramme de l'architecture du harnais Claw Code montrant la boucle utilisateur, la couche d'orchestration Python, le runtime Rust et les systèmes externes comme le fournisseur LLM, le système de fichiers et le serveur MCP.

Nœuds: 17Lanes: 4Complexité: ★★★★
Voir le modèle

Frontière Zero Trust pour MCP

Architecture de passerelle de sécurité MCP qui authentifie les appels d'outils, route l'exécution vers des sandboxes isolées, assainit les réponses et renvoie des résultats propres à l'agent IA.

Nœuds: 12Lanes: 3Complexité: ★★★
Voir le modèle

Contrôle d'accès à l'exécution

Architecture d'agent IA à privilège minimal avec évaluation par moteur de politique, accès just-in-time, identifiants à courte durée de vie et autorisations limitées à l'action avant l'exécution des outils.

Nœuds: 11Lanes: 3Complexité: ★★★
Voir le modèle

Validation humaine à risque gradué

Architecture d'approbation humaine dans la boucle qui classe les actions de l'agent par niveau de risque, route les demandes à haut risque vers un relecteur et écrit des journaux d'audit immuables.

Nœuds: 14Lanes: 4Complexité: ★★★★
Voir le modèle

Communication sécurisée multi-agents

Architecture de sécurité multi-agents avec jetons à portée limitée, application des règles par passerelle API, appels workers protégés par mTLS et agrégation des résultats par un orchestrateur.

Nœuds: 20Lanes: 4Complexité: ★★★★
Voir le modèle

Concevez votre propre diagramme d'architecture

Utilisez FlowZap pour créer, partager et documenter votre architecture système. Partez d'un modèle ci-dessus ou construisez de zéro — c'est gratuit.