Read Your Writes

• Sticky Sessions: Der Load Balancer schickt dich immer zum gleichen Server. Da dieser Server deinen Write hat, hast du RYW. (Simpel, aber Gefahr bei Server-Ausfall).
• Master Reads: Nach einem Write leitet die App alle Reads für 5 Sekunden an den Master (statt Slaves).
• Versionstoken: Der Client merkt sich "Ich bin bei Version 10". Er schickt das mit. Der Server sagt: "Ich habe nur Version 9." -> Server wartet oder leitet an anderen Server weiter.

1. Client-Centric Consistency

RYW gehört zu den "Client-Centric" Modellen (neben Monotonic Reads, Monotonic Writes, Writes Follow Reads). Im Gegensatz zu "Data-Centric" (Linearizability) geht es hier nur um die Sicht eines Clients.

2. Implementation in Mongo/Cassandra

• MongoDB: Caussally Consistent Sessions garantieren RYW.
• Cassandra: Man kann RYW erreichen, indem man mit QUORUM schreibt und liest (teuer). Oder durch Sticky Token Aware Drivers.

Das Sync-Problem in Async-Replication

Das Hauptproblem entsteht in Multi-Leader oder Leader-Follower Setups. Du schreibst deinen Post auf die Primary-DB in Frankfurt. Die schreibt lokal (Disk Commit) aus Performanzgründen "Asynchron". Das Frontend sagt "Erfolg!". Im Bruchteil einer Sekunde sendet das Frontend ein API-Read, doch der Loadbalancer verweist das Read routinemäßig auf eine Read-Replica in Paris. Die Sync-Queue vom Frankfurt-Log ("Follower-Lag") ist winzige 20ms zurück. Paris weiß nichts vom Post, gibt ein veraltetes Cache-Dokument zurück. "Read Your Writes" ist gebrochen. Der User ist frustriert.

Version Tokens und Causal Consistency

Die härteste Lösung ohne den Tod des Durchsatzes (z.B. Write-Locks auf allen Nodes): Monotone Uhren oder Versionierungs-Token (Lamport Timestamps / Vector Clocks). Wenn der User auf Frankfurt schreibt, funkt das Backend den finalen DB-Sync-Index (z.B. TxID: 9812) als Cookie/Header an den Client-Browser zurück. Das Frontend speichert das. Beim nächsten API-Read-Call heftet der Browser diesen Token an: Acceptable-TxID: 9812. Trifft das Read in Paris auf, vergleicht Paris seinen aktuellen lokalen Zustand. "Oh, ich bin erst auf Stand 9810". Paris blockiert (hält den Socket offen), wartet die 20ms Lag ab, bis die Replikation 9812 schließt, und antwortet dann erst präzise. Dies nennt man "Client-Centric Causal Consistency".

Sticky Routing (Das Proxy Pattern)

Eine technisch simplere DevOps-Lösung ist explizites "Session-Sticky-Routing" direkt im Loadbalancer / API-Gateway. Wir injizieren Logik: Jeder User-Request, der von einer JWT-Session kommt, die in den letzten 30.000 ms ein POST/PUT gefeuert hat (Write), wird per Header-Cookie gezwungen, das Read konsequent vom dedizierten Primary Master zu beziehen. Reine Leser (die seit 1 Minute nichts editiert haben) werden radikal auf die billigen Read-Replicas entladen. Das entlastet den Master enorm, bedient 99% des Traffics und schützt den frisch agierenden User davor, unter dem asynchronen Follower-Lag zu leiden.