Здравствуйте, takTak, Вы писали:

T>дб-сервера подписаны на это событие и обрабатывают асинхронно создание записи А и по прошествии обработки в свою очередь делают entryHasBeenSavedEvent, причём где-то там у тебя находится event / message handler, который считает для каждой записи A с Id = "c6e45efb-2908-45a3-bfa9-a58f6b9822fb" до трёх или пяти entryHasBeenSavedEvent's или сколько у тебя там разных инстанций базы
А, так ты хотел именно от всех шардов зеленый свет получить! Импровизированный countdown latch Я думал, что такое тоже не получится (может ли эластик генерировать в каком-то виде событие об окончании индексации, я совсем не уверен). Впрочем, ведь в эластике есть кажется готовый инструмент, по крайней мере раньше был — можно указать, что запись завершается только после репликации на N узлов вместо обычного кворума. Получается такая же схема как у тебя, прямо из коробки.
Ок, будь это не эластик, это даже могло бы сработать. Но с эластиком есть дополнительная засада, насколько я понимаю, эластик не сразу после окончания индексации способен найти записанные изменения: сегменты рефрешатся с некой задержкой, по умолчанию вроде не более до 1 секунды. Конечно можно вставить задержку в 1 сек, но ведь реально 1 сек может превратиться и в несколько большее время (скажем сервер сильно загрузили), заранее неизвестное. С учетом этого есть какие-то идеи?

T>все остальные клиенты могут увидеть запись А только после того, как она будет сохранена в той базе, к которой они непосредственно обращаются
Та же самая проблема: они могут обращаться то к одному шарду, то к другому — куда их пошлет балансировщик кластера БД. Поэтому они могут то видеть эту запись, то не видеть. Что тоже в общем-то фигово. Несколько лучше чем видеть/не видеть свои собственные изменения, но если надо чужой документ подредактировать то тоже не айс.

Slicer