PeterXa,
Целяком и полностью согласен с mayton .

Что касается самого механизма, то он ИМХО должен выглядеть
приблизительно следующим образом:

1. У каждой сущьности в один момент времени должна быть одна мастер нода,
производящая изменения.

2. Мастер нода должна передавать вектор изменений
всем подчиненным нодам.

3. Изменяющая нода должна запрашивать у мастер ноды
разделяемую брокировку ресурса.

4. Вместе с блокировкой можно отправить запрос на изменение,
и как результат получить в ответ вектор изменений.

5. Менеджмент очереди разделяемых блокировок и очередности изменений
должен производиться мастер нодой.

6. По некому алгоритму любая нода может забрать
на себя мастер роль над сущьностю,
в зависимости от состояния очереди блокировок.

7. Каждая нода может держать у себя историю всех изменений,
для поддержки конситентности.

8. Для этого все ноды должны иметь один общий-глобальный
счетчик-идентификатор изменения для всех сущьностей ( типа SCN).

mayton,

Мастер нодой , должна быть та , котора генерирует наибольшее
количество изменений.

Обработка ситуации отпадание мастер ноды,
отдельный вопрос для выбора умный-красивый( быстрый-надежный)
на этапе проектировки архитектуры межнодового взаимодействия.
В самом простом случае
либо
все замернет до истечения кипэлайв таймаутов,
либо
очень быстро сгенерирует 100500 байт мусорных данных.

mayton сделать перерасчёт.
Критический ключевой момент архитекруры.

Нафик ваще такая распределенная ситема нужна,
где при появлении соплей и чихов нужно делат полный рестарт,
а тем более перерасчет.

ИМХО Если связываться, то нужно делать систему надежной,
а производительность оптимизировать или наращивать железом, когда ее нехватает.