Spójność ostateczna (ang. eventual consistency) to model spójności danych w systemach rozproszonych, w którym repliki tego samego rekordu mogą przez chwilę różnić się między sobą, ale przy braku nowych zapisów wszystkie ostatecznie zbiegną się do identycznego stanu. Kluczowe słowo to „ostatecznie”: system nie obiecuje, że odczyt zaraz po zapisie zwróci najnowszą wartość — obiecuje tylko, że jeśli przestaniesz pisać, to po jakimś czasie każda kopia pokaże to samo.
Po co komu coś takiego? Bo w rozproszonej bazie dane są rozsiane po wielu węzłach, często w różnych centrach danych. Czekanie, aż każda replika potwierdzi zapis, zabija wydajność i dostępność — a gdy padnie sieć między węzłami, musisz wybrać: albo odrzucasz operacje (silna spójność), albo akceptujesz, że klienci chwilowo widzą różne wersje (spójność ostateczna). To dokładnie ten kompromis, który opisuje twierdzenie CAP: przy partycji sieci wybierasz między spójnością a dostępnością. Eventual consistency to świadoma decyzja na rzecz dostępności i niskich opóźnień.
Jak to wygląda w praktyce
Sztandarowy przykład to Amazon DynamoDB oraz Apache Cassandra. W DynamoDB domyślny odczyt jest właśnie eventually consistent i kosztuje o połowę mniej niż strongly consistent. Jeśli chcesz mieć pewność, że dostaniesz najświeższe dane, wymuszasz to flagą:
aws dynamodb get-item --table-name Users --key '{"id":{"S":"42"}}' --consistent-read
W Cassandrze sterujesz tym przez consistency level przy zapytaniu, np. CONSISTENCY QUORUM w cqlsh. Klasyczny scenariusz: zmieniasz zdjęcie profilowe, odświeżasz stronę i przez moment widzisz stare — bo trafiłeś na replikę, do której zmiana jeszcze nie dojechała. Sekundę później jest już dobrze.
Na co uważać
Najczęstszy błąd to traktowanie „eventually” jak „natychmiast”. Po zapisie nie zakładaj, że kolejny odczyt zwróci nową wartość — to klasyczne źródło bugów typu „user kliknął zapisz, a lista się nie odświeżyła”. Drugi mit: spójność ostateczna nie znaczy „dane mogą się pogubić”. Mechanizmy jak read repair, hinted handoff czy wektory wersji dbają o zbieżność. Trzecia pułapka: nie pakuj tego pod operacje wymagające twardych gwarancji — saldo konta bankowego czy stan magazynu przy rezerwacji to raczej kandydaci na transakcje ACID.
Pojęcia powiązane: silna spójność (strong consistency), twierdzenie CAP, model BASE (kontra ACID), replikacja, read repair, read-your-writes consistency, NoSQL.