Я на всякий случай еще раз обозначу, почему предложение takTak не получается реализовать.
Вот мне попалась статейка https://10consulting.com/2017/10/06/dealing-with-eventual-consistency/ — там описаны такие подходы как имитация, блокировка на стороне клиента через поллинг, блокировка на стороне сервера и подписка на окончание действия.
И это прекрасно работает, когда система не сразу обновляет состояние в ответ на запросы клиента, но хотя бы консистентна по читаемым данным (в смысле, любые запросы к одним и тем же данным, пока эти данные никто не изменил, дают один и тот же ответ). У них в статье "неконсистентность" имеется между разными данными в одной БД, а у меня проблема более общая — та которая в CAP-теореме — нестыковка между ответами разных узлов при чтении одних и тех же данных.
И вот из-за нее все эти подходы обламываются. К примеру, клиент делает поллинг сервера и находит что добавляемые данные прочитались. Он довольный продолжает работу, снова запрашивает эти данные — но теперь запрос попадает на другой шард, там этих данных пока еще нет и получается что рано было радоваться.

Come on, ну наверняка же тут на форуме люди должны быть в курсе проблемы =)

Slicer

Я на всякий случай еще раз обозначу, почему предложение takTak не получается реализовать.
Вот мне попалась статейка https://10consulting.com/2017/10/06/dealing-with-eventual-consistency/ — там описаны такие подходы как имитация, блокировка на стороне клиента через поллинг, блокировка на стороне сервера и подписка на окончание действия.
И это прекрасно работает, когда система не сразу обновляет состояние в ответ на запросы клиента, но хотя бы консистентна по читаемым данным (в смысле, любые запросы к одним и тем же данным, пока эти данные никто не изменил, дают один и тот же ответ). У них в статье "неконсистентность" имеется между разными данными в одной БД, а у меня проблема более общая — та которая в CAP-теореме — нестыковка между ответами разных узлов при чтении одних и тех же данных.
И вот из-за нее все эти подходы обламываются. К примеру, клиент делает поллинг сервера и находит что добавляемые данные прочитались. Он довольный продолжает работу, снова запрашивает эти данные — но теперь запрос попадает на другой шард, там этих данных пока еще нет и получается что рано было радоваться.

Come on, ну наверняка же тут на форуме люди должны быть в курсе проблемы =)

Slicer

P.S. Фальшивый объект мог бы сработать — если мы решим его вообще не обновлять автоматически, а так и держать на клиенте до тех пор, пока клиент не решит перечитать данные заново. Ну а если и правда решит? Например начнет в фильтр для поиска вбивать какие-то значения. Да, в 99% случаев к этому моменту нужные ему данные уже везде зальются. Но могут и не успеть =)