Согласованность в конечном счёте (БД)
Самая слабая из распространённых гарантий согласованности: если новых записей нет, все реплики в итоге придут к одному значению. Ничего не сказано ни о том, сколько это займёт, ни о том, что вы увидите в промежутке, — лишь о том, что рано или поздно реплики сравняются.
Идея: доступность и низкая задержка важнее немедленной согласованности. Реплики могут временно различаться (чтение сразу после записи способно вернуть «старые» данные), но механизмы восстановления (read repair, anti-entropy) обеспечивают сходимость. Классические примеры: DNS (изменение расходится минуты и часы), Cassandra/Dynamo в слабых режимах, S3 (исторически). Плюсы: высокая доступность, устойчивость к разделению сети, масштабируемость (AP в CAP). Цена: приложение должно мириться с устаревшими значениями и возможными конфликтами. Слово «в конечном счёте» известно своей расплывчатостью, поэтому поверх добавляют более сильные варианты — read-your-writes и причинную согласованность. Противоположность сильной (линеаризуемой) согласованности.