AT Protocol объяснил архитектуру децентрализованного бэкенда Bluesky

Статья на сайте AT Protocol («ATProto for Distributed Systems Engineers») пошагово показывает, как классический веб-бэкенд эволюционирует в децентрализованную сеть вроде той, что использует Bluesky.

Старт, типичная схема: сервер приложения и одна большая SQL-база. По мере роста добавляют кэши, затем горизонтально масштабируют базу через шардирование и реплики. Дальше статья разбирает условный, вымышленный пример, соцсеть на сотни миллионов пользователей (это иллюстрация, а не реальные цифры Bluesky), и показывает, что даже такая схема упирается в потолок: строгая консистентность (состояние синхронизировано по всей системе одинаково) стоит производительности.

Выход, ослабить требование до «согласованности в конечном счёте» (eventual consistency) и перейти на NoSQL-кластер. Но без SQL пропадают JOIN и агрегатные запросы: NoSQL по сути просто key-value хранилище. Решение, писать программы, которые заранее считают представления (views) данных и дублируют в них каноничные данные для скорости; статья называет такие сервисы view-серверами. Проблема: view-серверы могут падать и пропускать обновления, рассинхронизируясь с NoSQL-кластером. Чтобы этого избежать, вводят журнал событий (в статье как условный пример журнала назван Kafka, это иллюстрация подхода, а не заявление о реальном стеке AT Protocol), который записывает и рассылает все изменения; view-серверы слушают и при необходимости переигрывают журнал заново, поэтому не теряют обновления даже после рестарта. Итог, архитектура stream processing: она хорошо масштабируется, читающие запросы могут немного отставать от самых свежих данных, но записи не теряются и система не переходит в некорректное состояние.

Цель AT Protocol, связать разные приложения так, чтобы их бэкенды делили общее состояние, включая аккаунты пользователей и контент. Для этого внутренние компоненты только что описанной архитектуры (NoSQL-хранилище, журнал событий, view-серверы) превращают во внешние сервисы с публичными API: любой может поднять свой экземпляр каждого из них. Вместо одного NoSQL-кластера и одного view-сервера получается множество независимых серверов, которые работают вместе.

Чтобы это работало, вводят единую модель данных, «репозиторий данных пользователя». У каждого пользователя свой репозиторий; репозиторий делится на коллекции; каждая коллекция, упорядоченное key-value хранилище JSON-документов, которые называют записями. Раз репозитории может размещать кто угодно, им дают URL, а записям, собственную URL-схему; записи криптографически подписываются, чтобы при пересылке по сети можно было проверить их подлинность.

На практике приложение на AT Protocol обычно состоит из двух частей: сервера приложения (API и фронтенд) и view-сервера, который собирает данные из сети; их часто объединяют и называют Appview. Пользователь логинится через OAuth, указывает, на каком сервере хранится его репозиторий данных, и даёт приложению право читать и писать в него. Запись нового JSON-документа коммитится в репозиторий пользователя и порождает событие в журнале, который слушает репозиторий; событие уходит во все view-сервисы, которые на него подписаны, включая тот же самый Appview, который сделал запись, потому что записи одновременно создают и другие пользователи, и другие приложения. Получается круговой поток данных: запись → репозиторий → журнал событий → view-серверы → чтение в приложениях. Цель, чтобы сеть масштабировалась не только по нагрузке, но и по разнообразию приложений, которые делят общую открытую сеть.

В завершение статья объясняет замысел: AT Protocol соединяет технологии peer-to-peer с практиками высоконагруженных систем. Инженеры-основатели протокола раньше работали над IPFS и Dat (поимённо в статье никто, кроме советника, не назван); действующий технический советник, Мартин Клеппман, автор книги «Data Intensive Applications». Ещё до запуска Bluesky команда сформулировала требование «без шагов назад»: сеть должна быть такой же удобной и глобальной, как любое привычное соцприложение, оставаясь при этом открытой сетью. Посмотрев на федерацию и блокчейны, команда увидела в них ограничения масштабирования и вместо этого взяла за основу стандартные практики высоконагруженных бэкендов, применив к ним техники из peer-to-peer систем.

Ключевые факты

AT Protocol взял архитектуру масштабируемого бэкенда соцсети (NoSQL-хранилище, журнал событий, view-серверы) и открыл её вовне: каждый компонент стал отдельным сервисом с публичным API, который может поднять кто угодно.
Общая модель данных, «репозиторий данных пользователя»: у каждого пользователя свой репозиторий, в нём коллекции, в коллекциях, упорядоченные JSON-записи со своими URL и криптографической подписью.
Запись данных запускает круговой поток: коммит в репозиторий → событие в журнале → доставка во все подписанные view-серверы, включая тот же Appview, который сделал запись, потому что события создают и другие приложения.
Основатели протокола ранее работали над IPFS и Dat; технический советник, Мартин Клеппман, автор книги «Data Intensive Applications» (поимённо в статье назван только он).
Ещё до запуска Bluesky команда установила правило «без шагов назад»: сеть должна быть удобной и глобальной, как обычная соцсеть, но оставаться открытой; федерацию и блокчейны отклонили из-за ограничений масштабирования.

Почему это важно

Статья показывает конкретный инженерный путь от привычного веб-бэкенда до децентрализованной сети: не абстрактный манифест, а пошаговое объяснение, зачем в архитектуре Bluesky появились NoSQL-хранилище, журнал событий и view-серверы, и как открытие этих внутренних компонентов вовне даёт сеть, которую может расширять кто угодно.

Кому это важно

Инженерам распределённых систем и бэкенд-разработчикам, которые хотят понять устройство AT Protocol изнутри; тем, кто строит приложения поверх Bluesky/AT Protocol и должен понимать модель данных (репозитории, коллекции, записи) и поток событий; архитекторам, которые сравнивают децентрализованные подходы с федерацией и блокчейнами.

Как это применить

Разработчику приложения на AT Protocol нужны сервер приложения и view-сервер (вместе, Appview); пользователь логинится через OAuth и указывает сервер, где хранится его репозиторий данных, давая приложению право читать и писать в него; запись документа порождает событие в журнале, на которое подписывается собственный и чужие view-сервисы, это и определяет, как проектировать чтение и запись данных в приложении.

Можно ли доверять

Материал опубликован на официальном сайте atproto.com, это разбор архитектуры от самой команды протокола, без даты публикации и указания автора. В статье нет реальных цифр производительности, задержек или числа пользователей Bluesky: пример «соцсеть на сотни миллионов пользователей», условная иллюстрация внутри объяснения, а не заявленная статистика; Kafka в тексте назван лишь как пример возможного журнала событий, а не как подтверждённый производственный стек AT Protocol.

Риски и подводные камни

Ключевая плата за масштабируемость, отказ от строгой консистентности: читающие запросы могут отставать от самых свежих данных, хотя записи не теряются. Статья не приводит бенчмарков или сравнения с федеративными и блокчейн-архитектурами в цифрах, только качественное объяснение, почему их ограничения показались команде существеннее.

«Мы установили чёткое требование: «без шагов назад»»

— команда AT Protocol