Local-first застосунки й CRDT: як працювати офлайн без конфліктів синхронізації

Local-first застосунок зберігає робочу копію даних на пристрої та дозволяє редагувати її без постійного з’єднання. Синхронізація повертається пізніше, а CRDT може детерміновано об’єднати конкурентні операції, проте архітектура все одно потребує правил доступу, видалення й відновлення.

Локальна копія є повноцінним станом

Інтерфейс читає та записує локально, тому затримка мережі не блокує основні дії. Sync layer передає зміни між replicas. Користувач має бачити, чи дані лише локальні, синхронізуються, конфліктують із бізнес-правилом або вже підтверджені сервером.

CRDT вирішує не всі конфлікти

Структура гарантує convergence за визначених умов, але не знає, чи можна одночасно видати останній квиток двом людям. Унікальність, платежі, ліміти та юридичні approvals часто потребують координатора або явного workflow вирішення.

Ідентичність операцій важлива для повторної доставки

Кожна зміна має стабільний identifier, causal context і автора. Transport може повторити або переставити повідомлення, тому застосування повинно бути idempotent. Clock time пристрою не використовують як єдине джерело порядку.

Видалення й історія мають ціну

Tombstones та operation log ростуть, якщо їх ніколи не ущільнювати. Compaction можна виконувати лише коли система знає, що потрібні replicas побачили стан, або має snapshot і recovery protocol. Інакше старий пристрій здатен повернути видалені дані.

Що контролювати на практиці

Після впровадження варто відстежувати час локальної операції, sync lag, convergence failures, розмір журналу й частоту ручного вирішення. Показники порівнюють у тому самому сценарії, на тих самих пристроях або даних і з відомою версією налаштувань. Для критичних відхилень заздалегідь визначають безпечну дію та відповідального. Рішення переглядають, коли змінюється data model, CRDT library, access policy, retention або набір offline операцій. Такий журнал допомагає відрізнити реальне покращення від випадкової зміни умов.

Практичний чекліст

• визначити offline-capable операції
• показувати стан синхронізації
• відокремити CRDT від бізнес-інваріантів
• тестувати повтори й reorder
• спроєктувати compaction та recovery

Висновок

Найкращий вибір починається з конкретного сценарію, перевірки сумісності та малого тесту. Важливо документувати не тільки успішне налаштування, а й обмеження, резервний шлях та умови повторної оцінки. Тоді популярна технологія стає керованим інструментом, а не джерелом нової залежності.

Першоджерела: Ink & Switch — Local-first software; Automerge documentation.