Здравствуйте, takTak, Вы писали:
T>я не в курсе, как elasticSearch работает, я тебе о классическом CQRS рассказывал: там всё отправлением сообщений в очереди решается

Давай я пока подведу итоги, верно ль я понял тебя.
1. Можно было бы попытаться сделать через фейк на клиенте, если бы можно было каким-то образом получить от каждого узла БД подтверждение об успешной репликации.
2. Это бы дало возможность видеть собственные отправленные изменения. Но чужие изменения по-прежнему могут "мерцать" — их может быть то видно, то не видно. Конечно, в норме консистетность будет достигнута быстро и вероятность таких проблем минимальна. Но полного решения для просмотра чужих изменений без "мерцания" нет.

Далее, поскольку от Эластика не выйдет получить сообщение об успешном рефреше сегментов, то подход с фейком не сработает (ну или надо ставить дополнительную задержку еще на 1 секунду и молиться). Какие-то другие рабочие подходы есть? Которые не полагаются на ожидание таких сообщений. Например вроде должен работать подход с монотонностью, но он кажется опять требует специальной поддержки в используемой БД? Или можно все же привязать сессию пользователя к конкретному шарду БД (если это поддерживается), а в случае выхода шарда из строя, так и быть, рисковать появлением "мерцания" на какое-то время (да, это опять неполное решение, но если подумать, любое решение с fault tolerance и shared session не даст полной защиты от потери последних данных, если только это не будет некое CP решение — а тогда оно отправит псу под хвост availability и всей системы в целом). Опыта совершенно нет в этом, не представляю, какой путь лучше/общепринятый. А ведь проектов с тем же эластиком пруд пруди (хоть на джаве, хоть на вот этом вот MEAN стеке).

Slicer