Spójność ostateczna (DB)
Najsłabsza powszechna gwarancja spójności: jeśli nie pojawią się nowe zapisy, wszystkie repliki w końcu zbiegną do tej samej wartości. Nie mówi nic o tym, ile to potrwa ani co zobaczysz w międzyczasie — tylko że w końcu się zrównają.
Idea: dostępność i niskie opóźnienia ważniejsze niż natychmiastowa spójność. Repliki mogą chwilowo się różnić (odczyt zaraz po zapisie może zwrócić „stare” dane), ale mechanizmy naprawcze (read repair, anti-entropy) zapewniają ich zbieżność. Klasyczne przykłady: DNS (zmiana rozchodzi się minutami lub godzinami), Cassandra/Dynamo w słabszych trybach, S3 (historycznie). Zysk: wysoka dostępność, odporność na partycje, skalowalność (AP w CAP). Cena: aplikacja musi tolerować nieaktualne wartości i ewentualne konflikty. „Ostateczna” jest notorycznie nieprecyzyjna, więc silniejsze warianty, jak „read-your-writes” i spójność przyczynowa, dodają praktyczne gwarancje. Przeciwieństwo spójności silnej (linearyzowalnej).