Transaktionen bieten eine vollständige Konsistenz. Entweder wird alles in der Transaktion durchgeführt oder gar nichts. Sie bietet aber nur die Illusion einer sofortigen Konsistenz. Wenn das System zurück meldet, dass die Transaktion erfolgreich durchgeführt wurde, kann man mit Sicherheit davon ausgehen, dass die Änderungen auch verfügbar sind - das System hat eine sofortige Konsistenz.

Da hören die meisten Entwickler dann auch auf darüber nachzudenken¹⁾. Was, wenn das System einen unerwarteten Fehler meldet? Ganz einfach, Daten neu abfragen²⁾, das System ist ja vollkommen Konsistent, und wenn die Transaktion abgebrochen ist³⁾, und die Daten nach einem refresh nicht zu sehen sind, dann sind sie auch nicht da - wie einfach ist das denn.

Denkste, Puppe⁴⁾. Was, wenn der Fehler ein Verbindungsfehler war, der letzte Befehl aber noch abgearbeitet wird, während der Anwender das System nach den neuesten Daten abfragt? Obwohl der Anwender die Daten nicht sieht, könnte es durchaus sein, dass sie noch erscheinen werden. Man geht lediglich davon aus, dass die Zeit, die das System benötigt, um Befehle durchzuführen, wesentlich kürzer ist als die Zeit, die der Anwender benötigt, um die Daten nach einem Fehler zu aktualisieren. Man geht davon aus. Es ist auch in der Regel so, aber im Grunde ist das System bereits schlussendlich konsistent, man geht lediglich davon aus, dass es die notwendigen Daten schnell genug liefert, dass das eventual in eventual consistency eine natürliche Obergrenze hat.

Die natürliche Obergrenze ist bei transaktionalen Aktionen gefühlt kontrollierbar. Man kann sie sogar noch weiter kontrollieren, indem man einem Befehl ein Time-Out mit gibt. In dem Fall weiß man, dass das System nach ([Zeitpunkt der Empfangsbestätigung] + [Befehls Time-Out] + [Maximale Zeit einer Transaktion bis zu einem Transaktions Time-Out]) das Ergebnis des Befehls zur Verfügung haben muss.