Через девять лет после выхода первого издания Designing Data-Intensive Applications Мартин Клеппманн сместил фокус с привычного разговора о СУБД на куда более неудобную тему: кто вообще контролирует данные. В подкасте InfoQ он объяснил, почему децентрализованное хранение данных и local-first-подход перестают быть нишевой идеей для распределённых систем и становятся практическим вопросом для разработчиков, продуктовых команд и компаний, которые не хотят однажды обнаружить, что весь их продукт завязан на чужое облако.
Клеппманн, профессор Кембриджа и автор одной из самых цитируемых книг о современных системах данных, говорит об этом не в вакууме. По данным InfoQ, за последние десять лет архитектура хранения заметно изменилась: если раньше распределённые базы в основном писали поверх локальных дисков и сами занимались репликацией между узлами, то теперь всё больше систем строятся поверх object storage. Проще говоря, нижний слой хранения всё чаще отдан S3-подобным хранилищам, которые уже умеют жить в распределённой среде. Это меняет не только инфраструктурный стек, но и саму логику проектирования: вычисления и хранение данных разводятся по разным уровням, а база данных перестаёт быть единым монолитом, который делает всё сразу.
Для рынка это важный сдвиг. Несколько лет индустрия с азартом строила большие системы «всё в одном»: озёра данных, аналитические платформы, универсальные хранилища, где и ingestion, и хранение, и запросы, и управление метаданными поставлялись одним пакетом. Сейчас, по наблюдению Клеппманна, картина становится более модульной. Компании всё чаще комбинируют объектное хранилище, табличные форматы, файловые форматы и движки запросов как конструктор. Такой подход даёт больше гибкости: можно менять отдельные части стека без полной миграции, тестировать новые движки и не переписывать систему с нуля каждый раз, когда на рынке появляется очередная «лучшая» технология.
На словах это звучит как инженерный праздник, но за модульность приходится платить. Чем больше блоков в системе, тем выше требования к совместимости, наблюдаемости и дисциплине команд. И всё же Клеппманн считает этот разворот позитивным именно потому, что он снижает порог входа для экспериментов. Если раньше нужно было строить огромную платформу, то теперь можно сделать один сильный компонент и встроиться в существующий стек. Для стартапов это шанс не конкурировать лоб в лоб с гигантами на поле «полный data platform suite», а занять узкий, но востребованный слой. Для корпоративных команд это способ избежать тяжёлой зависимости от одного вендора, особенно если инфраструктура уже разъехалась между несколькими облаками и собственными площадками.
От облака к данным пользователя
Самая интересная часть разговора начинается там, где обсуждение уходит от архитектуры дата-платформ к конечному пользователю. Клеппманн проводит линию от облакоцентричных систем к децентрализованному хранению данных, ссылаясь на опыт Bluesky и его AT Protocol. Логика тут довольно простая: если все данные по умолчанию живут на сервере конкретного провайдера, пользователь получает удобство, но теряет агентность. Его история, контакты, контент и рабочий контекст оказываются привязаны к сервису, который может поменять правила, закрыться, сломаться или просто повысить цену выхода. Для B2C-сервисов это старая история про lock-in. Для B2B и внутренних продуктов всё ещё жёстче: зависимость от единственного облачного контура становится уже не только техническим, но и юридическим, финансовым и операционным риском.
Именно поэтому Клеппманн продвигает local-first-идею, в которой основная копия пользовательских данных находится на клиентском устройстве, а не где-то «вдали, но зато в managed-сервисе». Такой подход даёт как минимум три прикладных преимущества. Во-первых, офлайн-режим перестаёт быть мучительной спецфичей, которую команда годами обещает и откладывает. Во-вторых, пользователь или компания-заказчик меньше зависят от судьбы поставщика сервиса. В-третьих, архитектура становится ближе к нормальному ожиданию людей: мои данные должны быть у меня, а не только у того, кто дал мне к ним веб-интерфейс. Для российского рынка, где разговоры о цифровом суверенитете обычно быстро сводятся к дата-центрам и юрисдикции, это полезный разворот: суверенитет данных начинается не с стойки в ЦОДе, а с того, где лежит первичная копия и кто реально управляет её жизненным циклом.
Здесь, впрочем, нет наивной романтики про «полную федерацию и никакого центра». Клеппманн отдельно указывает на компромиссы децентрализации. Чисто федеративная модель красиво выглядит на схемах, но в реальных социальных и рабочих продуктах быстро упирается в необходимость глобального индексирования, поиска, согласованности и внятного пользовательского опыта. По этой причине пример Bluesky для него важен не как манифест «убираем все центры», а как попытка аккуратно развести уровни системы: сохранить переносимость данных и идентичности, но не сломать продукт настолько, чтобы им никто не захотел пользоваться. Для разработчиков это хороший холодный душ. Децентрализованное хранение данных не избавляет от сложных решений, а просто переносит их с уровня одной гигантской базы на уровень протоколов, синхронизации и правил доверия.
Что это меняет для разработчиков и бизнеса
Практическая часть разговора тоже без сюрпризов не обошлась. Клеппманн упоминает библиотеки вроде Automerge как основу для local-first-приложений: по сути, это механика, близкая к git-подобному контролю версий и совместной работе в реальном времени, но не только для текста. Он прямо говорит о применимости таких подходов к таблицам, CAD-файлам и другим нетривиальным форматам, где обычная схема «все изменения идут через центральный сервер» начинает мешать масштабированию и UX. Для инженерных команд это важный сигнал: local-first сегодня уже не сводится к заметочникам и редакторам документов. Подход начинает добираться до тяжёлых корпоративных сценариев, где конфликтующие изменения, офлайн-доступ и синхронизация между площадками являются нормой, а не экзотикой.
Для бизнеса вывод ещё прозаичнее. Если продукт строится на предположении, что центральное облако всегда доступно, всегда выгодно и всегда останется нейтральным посредником, то это слабое предположение. Чем дальше рынок уходит в модульные data-стеки и децентрализованное хранение данных, тем выше цена архитектурной лени. У команд появляются новые вопросы ещё на старте проекта: где живёт первичная копия данных, можно ли перенести идентичность и контент между провайдерами, что произойдёт при отключении центрального сервиса, как работает синхронизация при конфликтующих изменениях, кто отвечает за индексирование и кто в итоге контролирует доступ. Плохая новость в том, что эти вопросы сильно сложнее очередного выбора между SQL и NoSQL. Хорошая в том, что именно они всё чаще определяют, переживёт ли продукт следующий инфраструктурный поворот без дорогостоящей перестройки.
Главный тезис Клеппманна звучит неприятно для тех, кто привык считать облако окончательной точкой эволюции: похоже, следующий большой этап связан не с тем, как ещё удобнее хранить данные у провайдера, а с тем, как вернуть пользователю и компаниям контроль над ними, не развалив при этом продуктовый опыт. И если этот разворот закрепится, через несколько лет зрелость системы будут оценивать не только по latency, отказоустойчивости и стоимости хранения, но и по тому, насколько безболезненно данные могут жить вне конкретного вендора.