Architecture
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.
Code FlowZap complet
Client { # Client Application
n1: circle label:"User Action"
n2: diamond label:"Read or Write?"
n3: rectangle label:"Display Query Result"
n4: rectangle label:"Confirm Write Success"
n5: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> ReadPath.n10.handle(left) [label="Query"]
n2.handle(bottom) -> WritePath.n6.handle(top) [label="Command"]
n3.handle(right) -> n5.handle(left)
n4.handle(right) -> n5.handle(left)
}
WritePath { # Write Path (Command)
n6: rectangle label:"Command Validator"
n7: rectangle label:"Domain Aggregate"
n8: rectangle label:"Write Database (PostgreSQL)"
n9: rectangle label:"Publish Change Event"
n6.handle(right) -> n7.handle(left) [label="Validated"]
n7.handle(right) -> n8.handle(left) [label="Persist"]
n8.handle(right) -> n9.handle(left) [label="Committed"]
n9.handle(bottom) -> Sync.n14.handle(top) [label="DomainEvent"]
n8.handle(top) -> Client.n4.handle(bottom) [label="ACK"]
}
ReadPath { # Read Path (Query)
n10: rectangle label:"Query Router"
n11: rectangle label:"Read Database (Redis/Elastic)"
n12: rectangle label:"Transform to DTO"
n13: rectangle label:"Return Response"
n10.handle(right) -> n11.handle(left) [label="Optimized Query"]
n11.handle(right) -> n12.handle(left) [label="Denormalized"]
n12.handle(right) -> n13.handle(left)
n13.handle(top) -> Client.n3.handle(bottom) [label="JSON"]
}
Sync { # Synchronization Layer
n14: rectangle label:"Event Consumer"
n15: rectangle label:"Transform for Read Model"
n16: rectangle label:"Update Read Database"
n17: diamond label:"Lag Acceptable?"
n18: rectangle label:"Alert on Lag"
n14.handle(right) -> n15.handle(left) [label="Consume"]
n15.handle(right) -> n16.handle(left) [label="Upsert"]
n16.handle(right) -> n17.handle(left)
n17.handle(top) -> ReadPath.n11.handle(bottom) [label="Yes"]
n17.handle(bottom) -> n18.handle(top) [label="No"]
}
Pourquoi ce workflow ?
Applications with 100:1 read-to-write ratios waste resources when the same database handles both workloads. CQRS read-write separation uses optimized stores for each path—a normalized relational database for writes and a denormalized cache or search index for reads—enabling each to scale independently.
Comment ça fonctionne
- Step 1: Write requests go through the command validator and domain aggregate.
- Step 2: Validated changes are persisted to PostgreSQL (write-optimized, normalized).
- Step 3: A change event is published to the synchronization layer.
- Step 4: The event consumer transforms data and updates the read database (Redis or Elasticsearch).
- Step 5: Read requests are served directly from the optimized read store with sub-millisecond latency.
- Step 6: Lag monitoring alerts if the read model falls too far behind the write model.
Alternatives
Read replicas provide simpler read scaling but limit query optimization. Materialized views in PostgreSQL work for moderate read loads. This template shows the full CQRS separation with independent read/write stores.
Key Facts
| Template Name | Architecture CQRS de séparation lecture-écriture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
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.
Architecture
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.
Architecture
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.
Architecture
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.
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é.