La garantie monotonic reads (lectures monotones) est une propriété de cohérence des systèmes distribués répliqués. Elle appartient aux garanties de cohérence intermédiaires, situées entre la cohérence forte (linéarisabilité) et la cohérence éventuelle (eventual consistency).

Définition

Un système respecte la garantie monotonic reads si :
Pour un même client (ou une même session), les lectures successives d'une même donnée ne retournent jamais une version plus ancienne qu'une version déjà lue.

Autrement dit :

Si un client lit une valeur 
𝑣
1
v
1
	​

 à l'instant 
𝑡
1
t
1
	​

, puis une valeur 
𝑣
2
v
2
	​

 de la même donnée à l'instant 
𝑡
2
>
𝑡
1
t
2
	​

>t
1
	​

, alors 
𝑣
2
v
2
	​

 ne peut pas correspondre à une version antérieure à celle de 
𝑣
1
v
1
	​

.
Le système peut retourner des valeurs obsolètes par rapport à l'état global le plus récent, mais jamais de régression dans le temps pour un même client.

Formellement, chaque lecture d'un client doit observer un état de la réplique au moins aussi récent que celui observé par ses lectures précédentes (relation d'ordre sur les ensembles d'écritures visibles).

Contexte et utilité

Réplication : dans un système répliqué (Cassandra, DynamoDB, réplicas de lecture MySQL/PostgreSQL), deux lectures successives peuvent être servies par des répliques différentes, dont l'une est plus en retard dans l'application du flux de réplication. Sans monotonic reads, le client « recule dans le temps » : il voit un commentaire puis le voit disparaître.
Cohérence de session : combinée à read-your-writes, writes-follow-reads et monotonic writes, elle constitue les garanties de session, qui rendent le comportement intuitif pour un utilisateur donné.
Compromis performance / cohérence : plus faible que la linéarisabilité (pas de vue globale unique), mais plus forte que la cohérence éventuelle seule ; elle est peu coûteuse à implémenter.

Exemple

Exécution conforme (client A) :

Lecture Valeur lue Version

1 
10
10 v1
2 
12
12 v3
3 
12
12 ou 
15
15 v3 ou v4

Violation (client A) :

Lecture Valeur lue Version

1 
12
12 v3
2 
10
10 v1 interdit

Mise en œuvre typique

Affinité de réplique (sticky sessions) : router toutes les lectures d'un client vers la même réplique, par hachage de l'identifiant client.
Suivi de version côté client : le client conserve le timestamp logique / vecteur de versions de sa dernière lecture et exige une réplique au moins aussi à jour (sinon attente ou redirection).
Jetons de cohérence transmis dans la session (ex. : read-your-writes tokens).

Limites

Garantie par client uniquement : deux clients distincts peuvent observer des états divergents ; ce n'est pas une garantie globale.
Perte en cas de changement de session : si l'identité de session ou la réplique affectée change (basculement, expiration du jeton), la monotonie peut être rompue.
Ne dit rien sur la fraîcheur : une réplique très en retard reste conforme tant qu'elle ne régresse pas.

Références

D. B. Terry et al., « Session Guarantees for Weakly Consistent Replicated Data », PDIS, 1994 (formalisation des quatre garanties de session, dont monotonic reads).
A. Adya, « Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions », thèse MIT, 1999.
M. Kleppmann, Designing Data-Intensive Applications, 2017, chapitre 5 (« Replication »).