Согласованность в конечном счёте (Eventual Consistency)

Eventual consistency (согласованность в конечном счёте) — это модель согласованности, используемая во многих распределённых системах данных, которая гарантирует, что все копии (реплики) фрагмента данных со временем сойдутся к одному и тому же значению, при условии достаточного времени и отсутствия новых записей, — но не даёт никакой гарантии, что чтение сразу после записи увидит эту запись отражённой везде немедленно. Это осознанный компромисс, на который идут многие базы данных NoSQL и распределённые кэши в обмен на более высокую доступность и меньшую задержку записи, в противовес строгой согласованности (strong consistency), где каждое чтение гарантированно отражает самую свежую запись ценой более высокой задержки и сниженной доступности во время сетевых разделений — компромисс, формализованный CAP-теоремой. Почему это важно для разработчиков AI/SaaS-продуктов: eventual consistency вызывает особый, повторяющийся класс запутывающих багов, застающих команды врасплох при первой встрече с ним — пользователь обновляет свой профиль, сразу перезагружает страницу и на короткое время видит старые данные, потому что чтение было обслужено репликой, ещё не получившей обновление. В AI-продуктах это остро проявляется при записи в векторные базы данных: upsert нового эмбеддинга и немедленный запрос к нему могут в некоторых системах вернуть устаревшие результаты в течение короткого окна (часто от миллисекунд до нескольких секунд), пока запись полностью не распространится через индекс, — это важно для функций вроде «загрузить документ и сразу же искать по нему». Как это работает: распределённые системы достигают eventual consistency, асинхронно распространяя записи из места, где они были приняты, на все остальные реплики/узлы, не блокируя исходную запись до завершения этого распространения — исходная запись быстро возвращает успех, а согласованность во всей системе «догоняет» вскоре после этого. Некоторые системы предлагают настраиваемую согласованность, позволяя приложению выбирать для каждой операции, нужна ли ей строгая согласованность (ждать подтверждения от достаточного числа реплик, принимая более высокую задержку) или она может мириться с eventual consistency (вернуть результат немедленно, приняв короткое окно устаревания) — DynamoDB, Cassandra и несколько векторных баз данных предоставляют именно такой регулятор согласованности чтения/записи. Практический пример: пользователь загружает документ в AI-SaaS для базы знаний и через три секунды задаёт вопрос, ответ на который должен содержаться в этом документе, — но ANN-индекс векторной базы данных ещё не завершил включение нового эмбеддинга в свой доступный для поиска граф, поэтому запрос не возвращает релевантных результатов, и пользователь получает запутывающий ответ «у меня нет информации об этом», несмотря на то что только что загрузил именно этот документ. Решение: поток загрузки показывает состояние «обрабатываем ваш документ...» и включает интерфейс чата только после того, как бэкенд подтвердит, что эмбеддинг проиндексирован и доступен для запросов, скрывая окно eventual consistency от пользователя вместо того чтобы показывать его как запутывающий пробел.