Недостатки распределенной СУБД можно устранять административными методами.
Например склад и продажи: есть 100 шт товара который продают разные продавцы, разделенные каналами которые падают.
Вариант А: не давать продажу пока резервирование товара не произойдет в центральной БД. Тут продажа гарантированная, но при падении канала до центральной БД продаж 0.
Вариант Б: продавать столько сколько есть на остатке в локальной копии БД независимо от реальности. Тут продажи непрерывны, но есть вероятность продать сверх остатка. Для таких случаев надо предусмотреть административный механизм возврата денег покупателю или оповещение об отказе если деньги не успели получить. Ключевое слово "административный", т.е. четкий план действий если что-то пошло не так.

Я по второму варианту делал кассы в магазине. Успешная схема. Север падает или сеть падает или свет вырубают и касса на упсе но она работает и продает, т.е. берет деньги и выдает чеки. А то что иногда в таких ситуациях получается что продали 101 шт. товара которого было 100, так это проблемы бэкофиса, который в спокойной обстановке попатчит базу корректирующими документами. Зато хозяева довольны: упс помощнее (дизель-генератор) и торговля не прекращается даже при потопе.

И самое приятное в варианте Б: никто не ищет админа когда все рухнуло. Главное чтоб на кассе было электричество, в крайнем случае грузчик заведет дизель-генератор. Главное чтобы торговля шла, а косяки в базе могут и поболтаться до появления админа :)