CQRS et Event Sourcing : quand et pourquoi séparer lecture et écriture dans votre application ?
Obtenez un résumé intelligent et des insights personnalisés
Le CQRS (Command Query Responsibility Segregation) est un pattern d’architecture. Il sépare notamment les opérations d’écriture de celles de lecture. L’Event Sourcing, quant à lui, stocke chaque changement d’état sous forme d’événement immuable. De plus en plus d’experts associent actuellement CQRS Event Sourcing. Pour cause, cela offre une traçabilité complète et une lecture rapide. Ils ajoutent aussi de la complexité : nous les réservons aux systèmes à forte charge ou à forte exigence d’audit.
Une application classique lit et écrit dans la même base, avec le même modèle de données. Ce choix tient jusqu’au jour où les lectures ralentissent les écritures. C’est alors que le CQRS et l’Event Sourcing valent leur coût. Chez AquilApp, agence de développement web et mobile à Nantes, nous appliquons ces patterns aux backends d’applications web et d’applications mobiles.
Comment séparer commandes et les requêtes pour gagner en scalabilité avec le CQRS ?
Le CQRS est un pattern qui utilise un modèle pour modifier les données et un autre pour les lire. Greg Young l’a popularisé vers 2010, à partir du principe CQS (Command Query Separation) de Bertrand Meyer (Martin Fowler, 2011).
Une commande change l’état du système. Par exemple « valider la commande ». Ensuite, une requête lit cet état sans le modifier. Exemple « afficher l’historique du client ».
Ainsi, vous dimensionnez la lecture et l’écriture séparément. Sur un site d’e-commerce, les consultations du catalogue sont en général bien plus nombreuses que les commandes. Un modèle de lecture dédié absorbe ce trafic.
| Critère | CRUD classique | CQRS seul | CQRS + Event Sourcing |
|---|---|---|---|
| Modèle de données | Un seul modèle | Deux modèles (écriture, lecture) | Événements + vues de lecture |
| Montée en charge | Globale | Lecture et écriture séparées | Idem, avec relecture possible |
| Historique | État actuel uniquement | État actuel uniquement | Historique complet |
| Complexité | Faible | Moyenne | Élevée |
Sources : d’après Microsoft Learn, Azure Architecture Center (patterns CQRS et Event Sourcing) ; Martin Fowler, « CQRS » (2011).
Pourquoi stocker l’historique complet comme source de vérité avec l’Event Sourcing ?
L’Event Sourcing est un pattern qui enregistre chaque changement d’état comme un événement immuable. Le système calcule l’état actuel en rejouant ces événements dans l’ordre (Martin Fowler, 2005).
Prenons un compte bancaire. Vous ne stockez pas le solde de 1 250 euros. Vous stockez « dépôt de 1 500 euros », puis « retrait de 250 euros ». Le solde résulte de ces deux événements.
Le journal ne se modifie jamais : vous ajoutez uniquement de nouveaux événements. Pour éviter de tout rejouer, vous créez des instantanés (snapshots) à intervalles réguliers.
Comment réussir un CQRS Event Sourcing : la combinaison et ses synergies
Le CQRS Event Sourcing se complètent. Néanmoins, ils restent indépendants. En effet, le CQRS fonctionne très bien sans Event Sourcing. Donc, nous conseillons de commencer par lui seul.
Une projection est un programme qui écoute les événements et met à jour une vue de lecture. Le flux suit cinq étapes :
- L’API (Application Programming Interface) reçoit la commande.
- Le système vérifie les règles métier.
- Il enregistre l’événement dans l’event store, le journal d’événements.
- Les projections mettent à jour les vues de lecture.
- Les requêtes interrogent ces vues.
Cette combinaison permet de créer une nouvelle vue à tout moment. Il suffit de rejouer l’historique.
Quels sont les avantages du CQRS Event Sourcing : audit trail, scalabilité, replay et debug
Le CQRS Event Sourcing gagne du terrain. C’est bien grâce à quelques avantages :
- Audit trail (piste d’audit) : chaque modification garde sa date, son auteur et sa cause. Cette traçabilité renforce la sécurité des applications web.
- Montée en charge : vous ajoutez des serveurs de lecture sans toucher à l’écriture.
- Replay (relecture) : vous reconstruisez une vue ou corrigez une projection erronée en rejouant les événements.
- Debug : vous recréez l’état exact du système à une date précise pour reproduire un bug.
Quels sont les pièges à éviter : complexité, eventual consistency, projections
Martin Fowler prévient que le CQRS ajoute de la complexité à la plupart des systèmes (2011). Nous partageons cet avis. Quatre pièges reviennent le plus souvent.
- Complexité : plus de composants signifient plus de code, de tests et de supervision. Un CRUD suffit pour un back-office simple.
- Cohérence à terme (eventual consistency) : la vue de lecture se met à jour avec un léger délai après l’écriture. Dans une application mobile, l’interface affiche donc la modification en local avant la confirmation du serveur.
- Projections : une projection en erreur produit des vues fausses. Rendez-les idempotentes, c’est-à-dire capables de traiter deux fois un même événement sans double effet.
- RGPD : les événements sont immuables, mais l’article 17 du RGPD (Règlement général sur la protection des données) prévoit un droit à l’effacement. Stockez les données personnelles hors des événements, ou chiffrez-les avec une clé que vous pouvez supprimer.
Quel stack technique utilisée : EventStoreDB, Kafka, Axon Framework
Trois outils reviennent souvent dans ces projets.
| Outil | Rôle | Point fort | Limite |
|---|---|---|---|
| EventStoreDB (KurrentDB) | Base dédiée aux événements | Flux par entité, projections intégrées | Communauté plus restreinte |
| Apache Kafka | Plateforme de streaming d’événements | Débit élevé, diffusion entre services | N’est pas un event store complet |
| Axon Framework | Framework Java/Kotlin avec Axon Server | CQRS et Event Sourcing prêts à l’emploi | Écosystème lié à la JVM |
Sources : documentation officielle de Kurrent, d’Apache Kafka et d’AxonIQ.
Kafka diffuse très bien les événements entre services. Il ne propose pas nativement de flux par entité avec contrôle de concurrence. Nous recommandons de l’associer à un EventStore.
Évidemment, le langage influence l’outillage. Notre comparatif Node.js et Python vous aide pour le choix backend. Votre équipe utilise JavaScript ? NestJS propose un module CQRS officiel. Notre analyse Express.js vs NestJS vous aide à trancher.
Quand utiliser le CQRS Event Sourcing : fintech, e-commerce, logistique, santé
Il existe notamment plusieurs cas d’usage :
- Fintech : le journal des transactions sert de preuve lors d’un contrôle réglementaire.
- E-commerce : lectures du catalogue et écritures de commandes montent en charge séparément pendant les soldes.
- Logistique : un colis suit une suite d’événements (prise en charge, transit, livraison). Vous les rejouez pour retracer un litige.
- Santé : chaque accès et chaque modification d’un dossier restent tracés.
Pour créer un SaaS multi-clients, l’historique par client facilite aussi le support et la facturation à l’usage.
FAQ sur CQRS et Event Sourcing
Conclusion
Le CQRS Event Sourcing répondent à deux besoins : absorber une forte charge et conserver un historique fiable.
Notre conseil : commencez par le CQRS seul, puis ajoutez l’Event Sourcing si l’audit l’exige. En effet, ces patterns coûtent cher à maintenir. Donc, adoptez-les uniquement si le besoin est prouvé. Pour évaluer votre architecture, découvrez l’accompagnement de notre agence de développement logiciel sur mesure.
