Если максимально просто – каждый пользователь / приложение может локально иметь свой узел БД и взаимодействовать только с ним, а этот узел сам на заднем фоне будет синхронизироваться со всеми остальными узлами

Примеры: здесь отличный список

Из преимуществ

– Максимально быстрый ответ на действия пользователя / приложения
– Удобство разработки коллаборативных систем (об этом пониже)
– Возможность оперировать без интернета

Из недостатков

– Узкий набор доступных структур данных
– Имплементация алгоритма синхронизации или простая, но с низкой надежностью, или слишком сложная с высоким уровнем надежности, но с сильным упором на ГСУ ("господи спаси и убереги")
– Очень сложный дебагинг

Из особенностей

– Конкуренция решается засчет использования CRDT (самое простое объяснение, если найдете проще, киньте в комменты)
– Локи реализованы засчет "резервирования" данных на одном из узлов, с дальнейшей передачей владения другим узлам
– Очень важна правильная настройка какие данные может видеть / менять / хранить узел
– Может существовать "центральный" узел, владеющий всеми данными

Условия для использования

– Когда конфликтов быть не может – то есть, отсутсвие конкуренции, например, например засчет распределения владения на уровне архитектуры: БД является частью приложения, в котором работник на складе должен ходить и сканировать упаковки, внося какие-то данные. В момент времени всего 1 человек (работник) взаимодействует с конкретными данными, при это в центральном хранилище находятся все данные от всех работников.

– Когда клиенты сами могут разрешить конфликт – то есть, "коллаборация", а не "конкуренция". Например, Figma или Miro – даже если 2 человека одновременно перетянут одну карточку и кто-то сделал это не так как нужно, они смогут сами поправить это, когда увидят ошибку.

– Ну и понятное дело распределенные системы (то есть, вообще без центрального хранилища), но тут опять же или нужно жестко равпределять владение, или операться на коллаборативность, или валидация большинством

Итоги

Подобные базы данных нужны ТОЛЬКО в определенных кейсах (низкая или отсутствующая конкурентность), когда вы уверены, что они принесут больше пользы (оффлайн, скорость работы, распределение), чем недостатков (сложность разработки и дебагинга), а таких кейсов ну процентов 10 от силы.

Хотите больше distributed хардкора? Прошу

Я в свое время кайфанул от объяснения CRDT здесь https://jakelazaroff.com/words/an-interactive-intro-to-crdts/

А как ты с этим вопросом столкнулся? (Мотивация в этом разобраться)

Когда работал в Мегафоне, к нам время от времени заходили аналитики и просили накидать архитектуру примерно для одного и того же кейса: "есть завод / склад, на нем есть сотрудники, которые должны отмечать какие-то данные на выдаваемых Андроид телефонах, все это происходит в пердях практически без интернета или специально без интернета, придумайте архитектуру" – и все схемы всегда сводились к БД подобного рода (например, Cordova + PouchDB с синхронизацией на локальный сервер завода, где CouchDB)

А сам пытался разработать board game simulator для игры Unmatched и для онлайн коллаборации использовал yjs

Если есть накидай пжлста доп материалов по таким кейсам ? ( почитать по реализации )

О, и получилось с анметчед?

Я думаю, область применения намного шире.

Особенно, по мере появления разных регуляций, будет проще не обрабатывать данные у себя без крайней необходимости. Да, и пусть пользователь сам отвечает за безопасность у себя в браузере и т.п.

Не забывай про гит. Это ведь оно самое! CRDT-структуры можно использовать как гит.

Я всё хочу какое-нибудь приложение попробовать сделать с automerge. Руки не доходят. 😁

Я бы начал с чтения кейсов использования CouchDB и особенно Couchbase (потому что она платная)

На мой взгляд, это самые знаменитые продакшен решения подобного типа

А уже от чтения их кейсов можно будет найти и более современные аналоги

Собрал рендеринг на React + kanva, сделал свой ECS движок, механики спавна колоды, карт, шафла, healthbar, в общем нужный минимум заисключением смены глубины и вот в конце прикрутил yjs

Ну и дальше забил)

Хочу попозже вернуться и начать писать статьи по дороге чтобы систематизировать что получилось узнать

Кейсов точно намного больше, чем то, что я описал

Но факт проблемности дебагинга и очень высокой сложности обработки конкуренции (которая нужна большинству систем) вряд ли найдется решение для масс маркета в таких системах

Git попадает под мой второй пункт, где люди сами решают конфликты)