Entre les services, vous échangez généralement la cohérence forte pour la cohérence finale, et vous appuyez sur CQRS et event sourcing pour rendre cela pratique et correct.
Après une modification, les réplicas convergent « bientôt » plutôt qu'instantanément. Acceptable pour la plupart des flux métier (un compte d'inventaire peut avoir un décalage d'une seconde), inacceptable pour certains (une vérification de solde bancaire).
Séparez le modèle d'écriture d'un ou plusieurs modèles de lecture.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Les lectures se mettent à l'échelle et se restructurent indépendamment des écritures ; le modèle de lecture est mis à jour à partir d'événements, il est donc finalement cohérent.
Stockez la séquence d'événements comme source de vérité, pas seulement l'état actuel. L'état actuel est un repli sur les événements.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technique | Avantages | Coûts |
|---|---|---|
| Cohérence finale | Disponibilité, scalabilité | Lectures obsolètes, conflits |
| CQRS | Scalabilité lecture/écriture | Deux modèles à maintenir synchronisés |
| Event sourcing | Audit, rejoue, historique | Évolution du schéma/événements, complexité |
N'adoptez pas event sourcing partout — c'est puissant mais lourd. Utilisez-le où l'audit/historique compte vraiment.
Les systèmes distribués ne peuvent pas avoir la cohérence forte, la disponibilité et la tolérance aux partitions simultanément, donc la conception senior consiste à choisir où la cohérence finale est acceptable.
CQRS et event sourcing vous donnent les outils pour rendre la cohérence finale fiable et auditable — mais chacun ajoute une réelle complexité, alors appliquez-les de manière chirurgicale, pas par défaut.