Local-first синхронизация: CRDT, server-authoritative и WebDAV — что выбирать для офлайн-приложения

Аннотация

Когда приложению нужно работать офлайн, выбор модели синхронизации сводится к трём вариантам: CRDT-библиотека (Yjs, Automerge, Loro), server-authoritative движок (Electric, PowerSync, Zero) или WebDAV с расширениями CalDAV/CardDAV. Все три обещают одно и то же — данные на устройстве, синхронизация в фоне, — но контракты разные: у CRDT по проводу ходят обновления и state vector, у server-authoritative — операции upload/checkpoint или push/poke, у WebDAV — целые файлы и ETag. Обзор собран по первичным источникам: спецификациям IETF, документации движков, release notes, статьям авторов алгоритмов и трекерам проектов; данные на 2026-10-22.

Главный вывод: CRDT выигрывает там, где конфликт допустим по природе данных (текст, графика, заметки), и проигрывает там, где приложение обязано удержать инвариант (последнее место в зале, складской остаток, право на запись). Server-authoritative движки конфликты не устраняют — они переносят их в ваш API и схему БД, зато дают транзакции, права и предсказуемый размер локального кеша. WebDAV остаётся дешёвым общим знаменателем для нативных клиентов, но не умеет сливать изменения: разрешение конфликтов целиком ложится на клиент, а цена — целые файлы, слабые ETag и циклы 412.

Введение

Актуальность. Три лагеря двигаются одновременно. Automerge 3.0 сократил потребление памяти более чем на порядок, Eg-walker показал алгоритм совместного редактирования без постоянного хранения CRDT-метаданных, а Electric, PowerSync и Zero конкурируют за один и тот же класс приложений «Postgres плюс локальный кеш»¹²³. При этом в самохостинге WebDAV и CalDAV остаются единственным способом подключить нативные клиенты — от мобильных календарей до читалок⁴.

Цель — разложить три модели по контракту, гарантиям и операционной цене и показать, в каких случаях CRDT проигрывает обычному серверу, даже если формально «работает офлайн».

Границы. Не рассматриваются: специфика мобильных SDK, P2P-транспорт (WebRTC, libp2p), end-to-end шифрование как отдельная тема и коммерческие тарифы. Числа производительности взяты из публичных замеров авторов алгоритмов; независимого воспроизведения в этом обзоре нет.

1. Что обещает local-first и почему из этого не следует архитектура

Определение local-first сформулировано в эссе Ink & Switch как набор семи идеалов: «No spinners: your work at your fingertips», «Your work is not trapped on one device», «The network is optional», «Seamless collaboration with your colleagues», «The Long Now», «Security and privacy by default», «You retain ultimate ownership and control»⁵. Там же авторы осторожно называют CRDT технологией, которая «has the potential to be a foundational technology for realizing local-first software»⁵. Академическая версия тех же тезисов опубликована на Onward! 2019⁶.

Важно, что все семь идеалов описывают свойства пользовательского опыта, а не протокол. «Сеть опциональна» и «работа не заперта на одном устройстве» одинаково хорошо достигаются и CRDT, и сервером с локальным кешем: разница в том, где находится источник истины и кто принимает решение при расхождении. Отсюда три разных инженерных школы, которые ниже разбираются по отдельности.

Ещё одно следствие: local-first не означает «без сервера». В исходном эссе сервер прямо рассматривается как удобная резервная копия и помощник, а не как владелец данных⁵. Практическая разница между школами — не в наличии сервера, а в том, может ли клиент менять состояние, не спрашивая сервер.

2. CRDT: контракт «передай то, чего у меня нет»

Самый простой для понимания контракт — у Yjs. Спецификация y-protocols определяет три типа сообщений: SyncStep1 (отправитель передаёт свой state vector), SyncStep2 (ответ с отсутствующими у собеседника обновлениями) и Update (последующие локальные изменения)⁷. В клиент-серверной топологии клиент инициирует рукопожатие, сервер отвечает SyncStep2 и сразу добавляет свой SyncStep1, но сам рукопожатие не начинает⁷. Никакого «серверного порядка» в протоколе нет: обновления можно применять в любом порядке и повторно.

Рядом живёт awareness-протокол для эфемерного состояния (курсоры, присутствие): запись применяется, только если её clock строго больше локального, а клиент, не обновлявшийся 30 секунд, удаляется локально, поэтому каждый клиент должен переотправлять своё состояние не реже, чем раз в 15 секунд⁷. Это тот слой, который в демо выглядит как «курсоры коллег», а в продакшене определяет трафик: при 50 открытых вкладках обмен presence-сообщениями идёт постоянно, независимо от правок документа.

automerge-repo строит синхронизацию ещё абстрактнее: сетевой адаптер — это «any other instance of Repo which I am communicating with by message passing», поэтому в качестве транспорта годятся WebSocket, MessageChannel и BroadcastChannel⁸. Синхронизация при этом точечная: даже в широковещательном канале каждое сообщение дублируется для каждого пира, и документация прямо предупреждает, что BroadcastChannel «will in general be quite inefficient»⁸. Для самохостящегося сценария это означает, что «сервер» у Automerge — не арбитр, а ещё один пир с постоянным хранилищем.

Loro добавляет к этой картине инженерные компромиссы, которые полезно знать при выборе библиотеки. Модель данных — JSON-совместимая, синхронизация идёт через update и snapshot, а в сравнительной таблице проекта перечислены типы, которых нет у конкурентов: movable list, movable tree, event graph walker, Fugue для текста⁹. Там же честно указана цена: WASM-бинарник «~970KB gzipped», а в разделе «Consider alternatives when» первым пунктом стоит «Your application requires strong consistency»⁹.

Четвёртая форма того же лагеря — CRDT на уровне SQL. cr-sqlite — загружаемое расширение для SQLite и libSQL, которое «adds multi-master replication and partition tolerance to SQLite via conflict free replicated data types (CRDTs) and/or causally ordered event logs»¹⁰. Внутри — привычные примитивы: last-write-wins register, набор с причинной длиной, распределённый дробный индекс для пользовательских порядков сортировки¹¹. Привлекательность очевидна: разработчик объявляет таблицу и стратегию слияния, а не разбирается в алгоритмах; ценой становится то, что семантика конфликтов задана заранее и меняется только вместе со схемой.

Общее свойство всех четырёх реализаций: документ — это история. Каждое нажатие клавиши получает идентификатор, и метаданные нужно хранить, чтобы уметь сливать правки, пришедшие через неделю офлайна¹. Именно из этого свойства растут все дальнейшие ограничения — память, время загрузки и невозможность «просто удалить» данные.

3. Server-authoritative: сервер остаётся точкой истины

3.1 Electric: синхронизация только на чтение

Electric формулирует свою позицию без оговорок: «Electric Sync is a read-path sync engine for Postgres»³. Единица синхронизации — shape: таблица плюс необязательные where и columns¹². Шейпы однотабличные, а их определения неизменяемы: чтобы изменить фильтр, нужно создать новый шейп¹². При изменении схемы таблицы Electric инвалидирует все шейпы на ней — как по relation-сообщению из Postgres, так и фоновой сверкой метаданных раз в 60 секунд¹². На сервере есть и предел числа шейпов с вытеснением (ELECTRIC_MAX_SHAPES)¹².

Запись Electric не делает вовсе: «Electric does not do write-path sync. It doesn’t provide (or prescribe) a built-in solution for getting data back into Postgres from local apps and services»¹³. Документация предлагает четыре шаблона — от обычных онлайн-записей через свой REST API до «through-the-database» — и честно перечисляет цену первого: «You have the network on the write path… Applications won’t work offline»¹³. Иначе говоря, «local-first на чтение» — это архитектура, где офлайн-доступ к данным есть, а офлайн-запись нужно проектировать отдельно.

3.2 PowerSync: бакеты, контрольные точки и очередь выгрузки

PowerSync использует другую единицу — bucket, «a collection of synced rows, synced to any number of users», внутри которого поддерживается упорядоченная история операций PUT и REMOVE¹⁴. Бакеты параметризуются (например, user_todo_lists["A"]) и синхронизируются целиком, что позволяет одному инстансу сервиса обслуживать «tens of thousands of concurrent clients»¹⁴. Целостность держится на контрольных точках и контрольных суммах по бакету: если данные на сервере повреждены, сумма перестаёт совпадать и клиент перекачивает бакет целиком; чтобы история не росла бесконечно, она компактится маркерами¹⁴.

Запись идёт через очередь выгрузки на клиенте с тремя типами операций — PUT, PATCH, DELETE — и вашим собственным эндпоинтом на бэкенде¹⁵. Ключевое требование: эндпоинт должен быть синхронным по отношению к записи в базу, потому что «PowerSync uses a server-authoritative architecture with a checkpoint system for conflict resolution and consistency»; если клиент считает, что запись прошла, а следующая контрольная точка её не содержит, изменения с клиента удаляются¹⁵. Отсюда неочевидное правило: ошибки валидации и конфликты не следует возвращать как 4xx, потому что это блокирует очередь — рекомендуется отвечать 2xx и передавать детали ошибки отдельной записью, которая синхронизируется обратно¹⁵.

3.3 Zero: запросы вместо правил, mutators на обеих сторонах

Zero меняет единицу синхронизации ещё раз: синхронизируется не таблица и не бакет, а результат запроса, написанного в коде приложения, — «You control what syncs by writing normal queries in your app code, instead of syncing whole tables or maintaining static sync rules»¹⁶. Запись описывается mutator’ом, копия которого существует и на клиенте, и на сервере: клиент применяет её локально, отправляет запись о запуске на /push, сервер выполняет ту же функцию в транзакции, а изменения возвращаются клиентам через zero-cache¹⁷. Локальный эффект неприменённых мутаций откатывается, когда сервер подтверждает их применение¹⁷.

Это ближе всего к «оптимистичному UI с серверным арбитражем»: конфликтов как класса нет, потому что порядок задаёт сервер, а разрешение конфликта — это код вашего mutator’а. Цена — предсказуемость состояния: ответы кроме 200, 401 и 403 переводят клиент в состояние ошибки, 5xx повторяются до четырёх раз, а 401/403 требуют ручного переподключения¹⁷.

3.4 Figma как продакшен-референс

Самый старый публичный пример server-authoritative подхода — Figma: клиент при открытии скачивает копию документа, дальше обмен идёт по WebSocket, а при возврате из офлайна «the client downloads a fresh copy of the document, reapplies any offline edits on top of this latest state, and then continues syncing updates over a new WebSocket connection»¹⁸. Показательна и оговорка авторов: остальные данные (комментарии, пользователи, команды) живут в Postgres и синхронизируются отдельной системой, потому что «different tradeoffs around certain properties such as performance, offline availability, and security»¹⁸. То есть даже компания, построившая продукт на синхронизации, не использует одну модель для всех данных.

4. WebDAV: общий знаменатель без слияния

WebDAV решает задачу иначе: единица синхронизации — целый ресурс, а согласованность держится на условных запросах. В RFC 4918 заголовок If позволяет сделать запрос условным по ETag, и «if this header is evaluated and all state lists fail, then the request MUST fail with a 412 (Precondition Failed) status»¹⁹. CalDAV усиливает требование: DAV:getetag «MUST be defined and set to a strong entity tag on all calendar object resources»²⁰ — потому что именно ETag делает возможной офлайн-работу с последующим разрешением конфликтов²⁰.

Главное ограничение протокола сформулировано в самом RFC 4791: клиент «can only change the entire calendar object resource via a PUT request. There is currently no way to incrementally make a change to a set of calendar properties»²⁰. Никакого слияния на уровне полей нет — есть сравнение версий и решение клиента: перезаписать, отменить или показать конфликт пользователю.

Инкрементальность появилась отдельным расширением. RFC 6578 вводит отчёт DAV:sync-collection и DAV:sync-token: клиент присылает токен, полученный в прошлый раз, и получает список изменений с тех пор²¹. Сервер вправе урезать ответ — тогда он обязан вернуть 507 (Insufficient Storage) для request-URI и всё равно корректный sync-token, чтобы клиент мог продолжить постранично; клиенты обязаны обрабатывать этот 507²¹. Для дочерней коллекции, где отчёт не поддерживается, сервер обязан один раз вернуть 403 с элементом DAV:error²¹. Это описание того, как выглядит «нормальный» WebDAV-сервер; на практике соответствие различается.

Цена серверной стороны видна в документации sabre/dav — библиотеки, на которой построены многие CalDAV/CardDAV-серверы. Поддержка sync требует, чтобы для каждого изменения — добавления, удаления или модификации объекта — сервер «must track this change and store it somewhere»⁴. Зато выигрыш реальный: по оценке проекта, WebDAV-Sync «has been implemented by almost every Cal- and CardDAV client» и заметно сокращает число запросов, память и трафик⁴.

Обратная сторона — хрупкость деталей. В трекере KOReader описан цикл, в котором синхронизация зависает навсегда: сервер за сжатым ответом отдаёт слабый ETag W/"…", клиент подставляет его в If-Match, а If-Match требует строгого сравнения²², поэтому сервер корректно отвечает 412, клиент перезапрашивает файл, получает тот же слабый ETag и повторяет попытку бесконечно²³. Воспроизводится это на обычной связке Nextcloud за nginx или Cloudflare с включённым gzip²³. Это не экзотика, а типичный отказ self-hosted стека: протокол формально соблюдён обеими сторонами, приложение не работает.

5. Гарантии: конвергенция против инварианта

Ключевое различие между школами — не в наличии офлайна, а в том, какой класс ошибок они исключают. CRDT гарантирует сходимость: если все реплики получили один и тот же набор обновлений, итоговое состояние совпадёт. Формально это сильная конечная согласованность, и её проверяют машинно — например, в Isabelle/HOL, где авторы отдельно отмечают, что многие опубликованные алгоритмы репликации позже оказывались некорректными, «even some that were accompanied by supposed mechanised proofs of correctness»²⁴.

Сходимость не равна правильности. Автор Loro приводит пример, который стоит держать в голове при выборе архитектуры: приложение может поддерживать продажу билетов или бронирование, но «an operation such as allocating the last available seat requires coordination before it can be confirmed; independent offline edits alone cannot guarantee that the seat is sold only once»²⁵. Вывод автора: локальные чтения и черновики — пожалуйста, а операции, удерживающие общий инвариант, всё равно требуют координации²⁵.

Server-authoritative движки решают это иначе — не алгоритмом слияния, а тем, что запись проходит через транзакцию в базе. В PowerSync конфликт разрешает ваш эндпоинт, а движок лишь гарантирует, что подтверждённые изменения не будут затрёрты более свежим скачиванием¹⁵. В Zero разрешение конфликта — это код mutator’а, который выполняется на сервере, поэтому проверка прав и бизнес-правила пишутся обычным TypeScript¹⁷. Права доступа в CRDT-мире, наоборот, приходится строить снаружи: в спецификации Yjs прямо сказано, что «Yjs has no built-in concept of read-only peers», и предложен обходной путь — сервер смотрит на первые два байта сообщения и отклоняет SyncStep2 и Update⁷. Awareness-данные при этом не аутентифицированы вовсе, и «authoritative identity MUST be enforced at a higher layer»⁷.

У WebDAV своя логика: конфликт не разрешается, а обнаруживается. 412 — это сигнал клиенту, что версия изменилась, и дальше всё зависит от приложения: перечитать, слить по правилам домена, показать диалог¹⁹²⁰. Плюс в том, что модель понятна любому разработчику; минус — вся семантика слияния остаётся в клиенте, и каждый клиент реализует её по-своему.

6. Цена: история, память и время загрузки

Главный аргумент против CRDT на протяжении десяти лет — стоимость хранения истории. Automerge 3.0 — публичный ответ на него: библиотека перешла на сжатое представление не только «на диске», но и в памяти, и результат описан в блоге цифрами: «pasting Moby Dick into an Automerge 2 document consumes 700Mb of memory, in Automerge 3 it only consumes 1.3Mb»¹. Там же — про загрузку: документ, который «hadn’t loaded after 17 hours», стал загружаться за 9 секунд¹. Формат файла при этом не изменился, что важно для миграции существующих хранилищ¹.

Независимое академическое измерение даёт более трезвую картину. В статье об Eg-walker (EuroSys 2025) сравниваются CRDT, OT и гибридный алгоритм на трассах реального редактирования: «Yjs has up to a 3× greater memory use than our reference CRDT, and Automerge an order of magnitude greater»². Eg-walker хранит состояние как граф событий и пересобирает документ при слиянии, поэтому в установившемся режиме память «at least an order of magnitude lower than that of CRDTs», а загрузка документа с диска — на несколько порядков быстрее; на трассе A2 разница достигает «160,000× faster»². Слияние длинных веток, которое в OT занимает час, у Eg-walker укладывается в 24 мс².

Отдельная проблема — рост идентификаторов в sequence-CRDT при долгих сессиях. Авторы ESBT формулируют её прямо: существующие алгоритмы «often suffer from uncontrolled identifier growth and increasing memory consumption during long-running, highly concurrent editing sessions»²⁶. Их схема плотных идентификаторов на нагрузке до 100 000 конкурентных операций с 50 сайтов улучшает отзывчивость на 28–88% на чистых вставках²⁶. Практический смысл для самохостера: «документ, который живёт годами» — это не тот же сценарий, что «документ на одну сессию», и замеры на коротких трассах его не описывают.

Server-authoritative движки платят другую цену. PowerSync держит историю операций по бакетам и компактит её маркерами, чтобы размер не рос бесконечно, а целостность проверяет контрольными суммами¹⁴. Electric держит журнал шейпов на диске и переживает рестарт, если каталог хранения и replication slot сохранены, но вынужден инвалидировать шейпы при изменении схемы¹². Локальный кеш в этих движках предсказуем по размеру, потому что определяется вашим запросом или правилом, а не историей всех правок.

7. Операционные отказы, которых не видно в демо

Первое, что ломается при эксплуатации, — миграции. В Electric изменение схемы таблицы автоматически инвалидирует все шейпы на ней, и клиент вынужден пересинхронизироваться; неизменяемость определения шейпа означает, что «поменять фильтр» — это новая сущность, а не правка существующей¹². В CRDT-мире аналог проблемы — эволюция схемы внутри документа: старые клиенты не знают о новых полях, а слияние всё равно произойдёт, поэтому валидация переносится на уровень приложения.

Второе — семантика контрольных точек. Требование PowerSync о синхронном эндпоинте выглядит бюрократией, пока не прочитаешь объяснение: если клиент решил, что запись прошла, а контрольная точка её не содержит, изменения исчезнут с устройства «for a few seconds and then re-appear»¹⁵. Для пользователя это выглядит как «приложение съело мой текст», хотя формально всё согласовано.

Третье — хрупкость условных запросов. История с слабым ETag в KOReader показывает, что достаточно включённого gzip на прокси, чтобы синхронизация встала намертво, а цикл повторов не имел верхней границы²³. Мораль для того, кто пишет клиент: проверка версии должна иметь ограниченное число попыток и запасной путь, а не while 412 do retry.

Четвёртое — авторизация. В Yjs сервер обязан сам распознавать read-only пиров по префиксу сообщения, а awareness-канал не защищён от подделки присутствия⁷. В Zero права реализуются кодом mutator’а на сервере, но состояние авторизации влияет на соединение: 401 и 403 требуют ручного переподключения, а 5xx повторяются ограниченное число раз¹⁷. В PowerSync права определяются параметрами бакетов и JWT, а корректность записи целиком зависит от вашего API¹⁴¹⁵.

Пятое — пагинация. 507 в ответ на DAV:sync-collection — не ошибка, а приглашение продолжить с выданным токеном; клиент, который его не обрабатывает, теряет часть изменений молча²¹. Это редкий случай, когда спецификация подробно описывает частичный ответ, а реализация клиента об этом не знает.

8. Как выбирать: оси решения

Сравнение по свойствам, которые проявляются в эксплуатации, а не в презентации:

Практические выводы из этого разложения выглядят так. Для документов и креативных данных — текст, доски, заметки, графика — CRDT остаётся лучшим выбором, потому что сам продукт требует «слить, а не выбрать»⁵⁹. Для учётных данных, где важен инвариант и права, дешевле server-authoritative: транзакция в Postgres надёжнее, чем согласование в клиенте²⁵¹⁵. Для календарей, контактов и «файловых» заметок, к которым должны подключаться нативные клиенты, WebDAV с sync-collection — единственный вариант, который уже поддерживают почти все клиенты, и это приходится принимать вместе с его ограничениями⁴.

Смешанная архитектура — не компромисс, а норма. Figma держит документы в одной системе, а комментарии и пользователей — в Postgres с другой моделью синхронизации, именно из-за разных требований к производительности, офлайну и безопасности¹⁸. Electric предлагает строить локальный first-read на шейпах, а запись проводить через собственный API, и это осознанная позиция, а не недоделка¹³. Loro, начав с CRDT-библиотеки, пришёл к выводу, что движок синхронизации обязан брать на себя больше: «The essential complexity behind all of it has to move from the application developer to the sync engine»²⁵.

9. Дискуссионные вопросы и противоречия

«CRDT — фундамент local-first» против «CRDT недостаточно». Эссе Ink & Switch называет CRDT потенциально фундаментальной технологией⁵; в 2026 году автор Loro публикует текст с заголовком «CRDTs are not enough», где перечисляет дыры: какие документы загружать, что показывать, пока данные не доехали, как выглядят права и как переключаться между бэкендами²⁵. Противоречие кажущееся: эссе говорит о модели данных, критик — о продукте. Но для выбора это значит, что «взять Yjs» не решает задачу синхронизации целиком, а решает её часть.

«Automerge стал экономным» против «Automerge потребляет на порядок больше». Блог Automerge 3.0 сообщает о сокращении памяти более чем в 10 раз на конкретном примере¹; статья Eg-walker измеряет Automerge как потребляющий «an order of magnitude greater» памяти, чем эталонный CRDT². Оба утверждения могут быть верны одновременно: сравнение идёт с разными базами (Automerge 2 против Automerge 3; эталонный CRDT против библиотеки) и на разных корпусах. Для практика вывод один: ориентироваться на собственный корпус документов, а не на заголовки релизов.

«WebDAV — простой общий знаменатель» против «WebDAV требует журнала изменений». Для клиента протокол действительно прост: токен и список изменений²¹. Для сервера это обязанность вести журнал каждого изменения и уметь отдавать его страницами⁴. Простота клиента оплачена сложностью сервера, и в самохостинге это видно по разнице между «поддерживает WebDAV» и «поддерживает WebDAV Sync».

«Server-authoritative = без конфликтов». Формально конфликтов нет, потому что порядок задаёт сервер¹⁷. Практически конфликт переезжает в API: PowerSync прямо говорит, что 4xx при конфликте заблокирует очередь выгрузки, и советует возвращать 2xx с описанием ошибки¹⁵. То есть конфликт не исчезает, а превращается в запись «ваша правка отклонена», которую нужно показать пользователю.

«Local-first = без сервера». В исходном эссе сервер допустим и полезен как бэкап⁵; на практике почти все рассмотренные движки предполагают серверную компоненту, а «без сервера» остаётся нишевым сценарием для P2P.

10. Недостаточность данных

Публичных сравнений Electric, PowerSync и Zero на одной нагрузке найти не удалось: документация каждого проекта приводит собственные оценки масштаба — например, «tens of thousands of concurrent clients per PowerSync Service instance»¹⁴ — без методики замера и без воспроизводимого бенчмарка. Поэтому утверждения о том, что один движок «быстрее» другого на рабочей нагрузке, в этом обзоре не делаются.

Не найдено и данных о том, как часто в реальных приложениях возникают семантические конфликты, требующие решения человека. Все рассмотренные источники либо проектируют механизм, либо описывают отдельный инцидент²³, но не приводят статистику по парку приложений.

Отдельный пробел — матрица поддержки DAV:sync-collection среди самохостящихся серверов. Документация sabre/dav говорит о поддержке в библиотеке⁴, спецификация описывает поведение при частичных ответах²¹, но сводной таблицы «сервер — поддерживает/нет — известные дефекты» нет, а именно она нужна при выборе между Nextcloud, Radicale и другими.

Наконец, числа Eg-walker, ESBT и Automerge получены на разных корпусах документов и в разное время. Прямое сравнение «сколько памяти на мегабайт текста» между ними некорректно, и в таблицах выше оно сознательно не приводится.

11. Заключение

Три модели синхронизации отвечают на разные вопросы. CRDT отвечает «как слить изменения, не спрашивая сервер» и платит за это историей, памятью и отсутствием встроенных прав. Server-authoritative отвечает «как не потерять инвариант и права» и платит сетевым участием на записи, зависимостью от схемы и тем, что конфликт переезжает в ваш API. WebDAV отвечает «как подключить любой существующий клиент» и платит отсутствием слияния, целыми файлами и хрупкостью условных запросов.

Практическая рекомендация для того, кто выбирает сегодня: начинать не с библиотеки, а с вопроса «что именно нельзя потерять». Если ответ — «ни одного нажатия» (документы, доски, заметки), это CRDT, и тогда бюджет нужно закладывать на память и на отдельный слой прав. Если ответ — «инвариант и права» (бронирования, остатки, платежи), это server-authoritative, и тогда бюджет уходит на проектирование API записи и на обработку отказов очереди. Если ответ — «нативные клиенты, которые уже есть» (календарь, контакты, файлы), это WebDAV, и тогда бюджет уходит на тестирование с реальными серверами и прокси.

Смешанный вариант перестал быть экзотикой: read-path синхронизация плюс собственный API записи (Electric), CRDT плюс серверный слой прав, документы в CRDT плюс справочники в Postgres (Figma). Направление развития тоже показательно: Eg-walker и ESBT сокращают разрыв между CRDT и алгоритмами с центральным порядком, а авторы CRDT-библиотек всё громче говорят, что сама библиотека — не продукт²²⁶²⁵. Следующий содержательный вопрос для этой линии обзоров — как выглядит серверный слой прав и аудита поверх CRDT, когда приложение обязано доказывать, кто и когда изменил данные.

Quality Metrics