Read-Your-Writes (auch Read-My-Writes oder RYW) ist eine Session-Garantie in verteilten Systemen: Sobald ein Client einen Schreibvorgang ausgeführt hat, sehen alle nachfolgenden Lesevorgänge derselben Sitzung diesen Wert — oder einen neueren. Systeme dürfen bleiben, was sie schreiben, selbst wenn andere Clients die Aktualisierung erst später sehen.
Warum ist die Garantie nötig?
In replizierten Systemen mit Eventual Consistency kann ein Lesevorgang theoretisch jede beliebige Replik treffen. Schickt ein Client nacheinander Anfragen an verschiedene Server, könnte er seinen eigenen soeben geschriebenen Wert wieder verlieren — etwa: Benutzer aktualisiert sein Profil, die Seite zeigt beim nächsten Klick aber noch den alten Stand. Read-Your-Writes verhindert genau dieses „Verlieren der eigenen Änderung".
Wie wird es umgesetzt?
- Sticky Sessions: Alle Anfragen einer Sitzung werden an dieselbe Replik geroutet, die den Write bereits verarbeitet hat. Einfach, aber anfällig bei Replik-Fehlern.
- Versions-Vergleich: Der Client merkt sich die letzte geschriebene Version; vor dem Lesen prüft die Replik, ob sie mindestens diesen Stand hat — notfalls wartet sie auf die Replikation (Replikationsnachzug).
- Quorums-Logik: Write-Quorum und Read-Quorum so wählen, dass der Leser garantiert eine Replik mit dem frischen Stand trifft (Quorum).
Wo kommt es praktisch vor?
Read-Your-Writes ist ein Standardverhalten für Datenbanken mit tunable consistency: Nach einem INSERT oder UPDATE liefert ein direkt folgendes SELECT derselben Sitzung in der Regel sofort den neuen Stand. Auch Warenkörbe, Kommentarfunktionen und Profilseiten setzen es voraus, damit Benutzer ihr eigenes Handeln unmittelbar sehen. Zusammen mit Monotonic Reads gehört es zu den vier Session-Garantien aus dem Grundlagenpapier von Douglas Terry et al., „Session Guarantees for Weakly Consistent Replicated Data" (PDIS 1994); die weiteren sind Writes-Follow-Reads und Monotonic Writes.
Read-Your-Writes betrifft nur die eigene Sitzung — es ist die schwächste sinnvolle Absicherung gegen Sharding- und Replikations-Artefakte und gut mit dem CAP-Theorem vereinbar: Man erkauft die Garantie mit etwas Latenz und Routing-Aufwand, nicht mit Verfügbarkeitsverlust. Eng verwandt: CRDTs lösen das Konfliktproblem bei konkurrierenden Writes koordinationsfrei, während die Session-Garantie nur die eigene Sicht absichert.