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


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

такой вариант, когда в одном узле запись есть, а через секунду в другом узле ещё нет, при CQRS практически невозможна, CQRS как раз и занимаются, чтобы скорость прохождения сообщений максимально увеличить

если все твои узлы / базы подписаны на сообщение и параллельно одно и то же сообщение начинают обрабатывать, то почему через секунду оно не должно быть быть обработано на другом узле? транзакций (блокировок) ты не используешь, скалировать по горизонтале можешь до бесконечности, почему обработка должна длиться дольше сотни миллисекунд?