К основному содержимому
#DistributedSystems

Local-First Software: Taking Back Control of Our Data a mini-doc (Рубрика DistributedSystems)

#DistributedSystems #Architecture #SystemDesign #Software #Databases

Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.

Основные идеи концепции такие 1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа. 2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным. 3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы. 4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.

Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее

  • Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета) - Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка. - Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена. - Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака. - Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.

В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.

P.S. Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)

P.P.S. Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.

#DistributedSystems #Architecture #SystemDesign #Software #Databases