Eventual Consistency

Contexte

Dans les systèmes distribués, maintenir une cohérence forte entre tous les nœuds a un coût élevé en latence et en disponibilité.

Le théorème CAP montre qu'un système distribué ne peut garantir simultanément :

Consistency — tous les nœuds voient la même donnée
Availability — chaque requête reçoit une réponse
Partition tolerance — le système fonctionne malgré des coupures réseau

Principe

L'eventual consistency est un modèle où :

Les données finiront par être cohérentes sur tous les nœuds, mais pas nécessairement immédiatement.

Après une écriture, il existe une fenêtre pendant laquelle différents nœuds peuvent retourner des valeurs différentes. Une fois la propagation terminée, tous les nœuds convergent vers la même valeur.

Exemple concret

Service A écrit "solde = 500" dans sa base locale
     │
     ▼
Événement publié sur Kafka
     │
     ▼
Service B consomme l'événement (délai de quelques ms à quelques secondes)
     │
     ▼
Service B met à jour sa read model → "solde = 500"

Pendant le délai de propagation, Service A et Service B peuvent retourner des valeurs différentes.

Strong vs Eventual Consistency

Aspect	Strong Consistency	Eventual Consistency
Lecture après écriture	Toujours à jour	Potentiellement stale
Latence	Plus élevée	Plus faible
Disponibilité	Réduite pendant les partitions	Maintenue
Complexité	Protocoles de consensus (Raft, Paxos)	Propagation asynchrone
Cas d'usage	Transactions bancaires critiques	Feeds, dashboards, caches

Patterns associés

Compensation

Quand une incohérence est détectée, un mécanisme de compensation corrige l'état :

saga pattern avec rollback compensatoire
reconciliation jobs périodiques

Read-your-writes

Pour améliorer l'expérience utilisateur, on peut garantir qu'un utilisateur voit ses propres écritures :

lire depuis le leader après une écriture
utiliser un version token côté client

Idempotence

Les messages peuvent être délivrés plusieurs fois pendant la convergence :

chaque consumer doit être idempotent
utiliser un eventId unique pour dédupliquer

Quand l'utiliser

systèmes event-driven avec CQRS
microservices avec bases de données séparées
caches distribués
systèmes à forte charge où la disponibilité prime

Quand l'éviter

transactions financières critiques nécessitant une cohérence immédiate
systèmes où une lecture stale peut causer des dommages (ex : stock critique)
workflows où l'ordre strict des opérations est requis

À retenir

eventual consistency est un compromis, pas un défaut
la fenêtre d'incohérence doit être mesurée et monitorée
les patterns d'idempotence et de compensation sont indispensables
le choix entre strong et eventual dépend du contexte métier, pas de la technique