Monotonic Reads ist eine Session-Garantie für verteilte Systeme: Liest ein Client innerhalb einer Sitzung einen Datenwert, so darf er später nie wieder eine ältere Version desselben Wertes sehen. Die gelesene Sicht bewegt sich nur vorwärts — praktisch „keine Zeitreise" beim Lesen.

Das Problem dahinter

Bei Replikation mit Verzögerung können unterschiedliche Repliken unterschiedliche Versionen eines Datensatzes halten. Ohne Garantie könnte ein Client zuerst eine frische Antwort von Replik A erhalten (Version 5) und im nächsten Request von Replik B wieder den alten Stand (Version 3). Nutzer sähen etwa eine Seite erst mit neuen Daten und dann plötzlich wieder mit alten — verwirrend und inkonsistent.

Umsetzungsmuster

  • Version merken: Der Client oder die Sitzung trackt die höchste gesehene Version beziehungsweise den höchsten logischen Zeitstempel. Jede nachfolgende Replik muss mindestens diesen Stand liefern.
  • Sticky Routing: Requests einer Sitzung bleiben an derselben Replik haften, die keine älteren Stände mehr ausliefert.
  • Logische Uhren: Konsens-Systeme und verteilte Uhren (Lamport-Uhren, HLC) liefern die Vergleichsgrundlage, um Versionen zu ordnen.

Einordnung

Monotonic Reads ist eine der vier Session-Garantien von Terry et al. („Session Guarantees for Weakly Consistent Replicated Data", PDIS 1994) neben Read-Your-Writes, Writes-Follow-Reads und Monotonic Writes. Systeme wie Cassandra oder DynamoDB-artige Stores erfüllen sie typischerweise pro Sitzung, wenn Clients stabil an eine Replik gebunden werden. Sie ist schwächer als starke Konsistenz, aber deutlich billiger: kein Quorum für jeden Lesevorgang nötig, kein Blockieren bei Netzproblemen — ein praktischer Kompromiss für hochverfügbare Anwendungen. Zusammen mit CRDTs bilden die Session-Garantien das Handwerkszeug für Systeme, die Skalierung und Benutzererwartung in Einklang bringen wollen.