Monotonic Reads

• Replica Selection: Der Client merkt sich den Timestamp des letzten Reads. Er schickt diesen Timestamp an den Load Balancer. Der Balancer leitet ihn nur an Server weiter, die mindestens so aktuell sind. Wenn kein Server so aktuell ist, muss der Client warten (besser warten als "Datenverlust" gaukeln).

1. Session Guarantees

Gehört wie "Read Your Writes" zu den Session Guarantees. Oft zusammen implementiert ("Monotonic Reads + Read Your Writes + Monotonic Writes + Writes Follow Reads"). MongoDB und CosmosDB bieten das als konfigurierbares Level an.

2. Implementation

Jeder Server führt ein Oplog mit Transaktions-IDs (z. B. Lamport Clock). Client speichert last_read_id = 500. Request: read(key, min_id=500). Server mit current_id = 490 antwortet: "Bin noch nicht so weit, versuch es woanders oder warte."

1. Vector Time & Causal Dependencies im Router

Wie weiß der API-Gateway eines AWS Cloud-Clusters wirklich ob ein Read noch monoton ist, wenn sich Millionen Schreib-Log-Transaktionen über hunderte Regionen verstreuen? Man injiziert oft partielle Vektoruhren (Gossip-Protokoll Zeitstempel, bestehend aus [Replika_1: 45, Replika_2: 12]) exklusiv passiv in den User-Session Cookie des Kunden Browsers! Klickt der User durch den Warenkorb auf Read(), transportiert der HTTP Header zwingend die High-Watermark seiner zuletzt gelesenen Realität zur Datenbank (Read_Vector_Context). Der Loadbalancer (Apache Cassandra Coordinator-Node) inspiziert seine eigene Version mit der Session-Markierung. Fällt die lokale Replika hinter den Session-Vektor ($Node Clock < Cookie Clock$), feuert der Node eine ReadRepair Warnung intern im Backbone-LAN zum Master DataCenter, um ein "Fast Forward Catch-Up" zwingend abzuschließen, bevor er das API-OK HTTP 200 zur Kunden Node schickt, denn Daten rückwärts ausrollen wäre "Zeitverzerrung".

2. CAP-Theorem vs Monotonicity Trade-offs

Im Schatten des CAP-Theorems bezahlt der Architekt jede Safety-Stufe zwingend mit Availabilty. Verlangt man knallharte Strong Consistency (wie in SQL durch ACID), hat man Monotonic Reads trivial kostenfrei garantiert. Erleiden wir jedoch eine Partition (P im CAP, Kabel gerissen im Atlantik), zwingt die Monotonic-Reads Session-Policy unser System unbarmherzig zu einem fatalen Aussetzer! Da der User in Paris das letzte Update per Europa-Node um 14:00 verifizierte, ihm der Proxy Loadbalancer kurzfristig via Geo-Routing aber die abgeschnittene US-Basis routet (Datenstand 13:50 Uhr wegen Kabelriss), muss die US-Nodes dem Request unweigerlich hart das Lesen der Festplatte als 500er Request verweigern! Es lehnt den Call ab, obwohl der Server "up and running" ist (C over A geopfert). Man muss also High-Availability strikt unter Kausal-Session-Konsistenz-Verfügbarkeits-Risiko setzen!

3. Sticky Sessions & Der Cache-Ping-Pong Bug

Die primitive Low-Cost Architektur zur Monotonie im Web (statt schwerer Vector-Clocks oder State-Passing) heißt Sticky Load Balancing. Ein Nginx Proxy fälscht Konsistenz über pures IP-Hashing. Wenn der Client IP X einloggt, hasht der Balancer das Paket dauerhaft zu exakt Node 3. Der User zirkuliert stoisch im isolierten State-Kosmos von Replica 3 und liest stets linear nach vorne. Der architektonische Total-Crash (Cache-Ping-Pong-Bug): Meldet der Pod Node 3 im Kubernetes per Health-Check "Failed", dreht Ingress den IP-Hash im Live-Betrieb schicksalhaft um auf Node 1. Node 1 ist aber durch Lags 2 Minuten Out-of-Sync. Der Browser des Users knallt ins Frontend GUI, der Warenkorb (bisher auf 12 Euro verbucht) springt radikal schockhaft auf 0 Euro zurück! Der "Ghost-Reset" bringt User zur Weißglut und deckt das Totalversagen von Sticky-Sessions mangels tief verankerten Gossip-Commit Protokollen erbarmungslos auf.