Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Короче, какое бы решение я ни рассматривал, ко всякому вроде бы можно придумать такой сценарий, при котором клиент может не увидеть только что внесенные им изменения. Или то видеть их, то не видеть.
SM>Slicer


Вы пытаетесь получить строгую consistency на базе системы с delayed consistency. Если говорить в терминах acid, то речь идет об Атомарности (A).

Варианта у вас два (на самом деле три, но об этом позже):
1) Подождать пока consistency наступит. То есть после нажатия "сохранить" держать пользователя "сохраняю" пока не удастся получить от хранилища документ.
2) Сохранить в локальный кеш и обращаться к данным кеша, пока из хранилища не придет подтверждение о сохранении. Тогда нужно организовать какой-то фоновый процесс, который будет очищать кэш при подтверждении или просто время хранения в кеше выставлять равным удвоенному среднему времени прихода подтверждения.

В целом такие проблемы могут быть решены если у вас есть одно-узловая consistency. То есть система в целом eventual consistent, но если все запросы приходят в один и тот же узел, то выполняется требование строгой consistency.
Но, как я понимаю elastic search не обладает таким свойством.

Третий вариант — отказаться от не-ACID хранилищ для транзакционных задач. Вы по факту потребовали от системы атомарности (A) и долговечности (D) с точки зрения ACID, зачем пытаться решать задачу на системе, которая не дает таких гарантий?
Более того, внутри ACID СУБД лежит delayed consistency система с логом и данными на дисках, и СУБД применяет локальный кеша в памяти для "грязных" страниц до того как они реально записаны на диск.
Так что все, что можно изобрести поверх delayed consistency уже изобретено внутри СУБД.