Классический бэкенд — это одна большая SQL-база за сервером приложения. Когда нагрузка растёт, добавляют кэши, шардирование и реплики. Но SQL требует сильной согласованности: все реплики должны быть синхронизированы в каждый момент, а это дорого. Если ослабить требование до eventual consistency, можно масштабироваться дальше — и тогда переходят на NoSQL-кластер.
Но без SQL теряются JOIN и агрегатные запросы. NoSQL превращается в простое key-value хранилище, и писать фичи становится больно. Решение — заранее вычислять представления данных, своего рода кэшированные запросы. Это view-серверы. Они дублируют канонические данные, чтобы отдавать их быстро. Синхронизировать их с NoSQL сложно: view-серверы падают и пропускают обновления. Поэтому появляется журнал событий — например, Kafka. Он записывает и рассылает все изменения кластера, а view-серверы слушают и переигрывают журнал, чтобы ничего не потерять даже после рестарта.
Так получается stream processing архитектура. Она хорошо масштабируется: чтение иногда отстаёт, но записи не теряются и состояние не портится. По сути, это база данных, вывернутая наизнанку: каноническое хранилище упростили до NoSQL, а собственный query-движок собрали из view-серверов.
Цель AT Protocol — соединить приложения так, чтобы их бэкенды делились состоянием: пользователями, контентом. В обычной схеме наружу торчит только app server, а всё остальное изолировано. Нужно сломать изоляцию и сделать внутренние сервисы внешними: у каждого появляется публичный API, и любой может поднять свой экземпляр. Так возникает децентрализованный бэкенд из множества NoSQL-кластеров, view-серверов и журналов.
Чтобы они работали вместе, вводится общая модель данных — user data repository. Каждый репозиторий хранит JSON-документы, которые называются records, и собирает их в коллекции. NoSQL-хранилища «опинионизируются»: у каждого пользователя свой репозиторий, у репозитория — коллекции, у коллекции — упорядоченное key-value хранилище JSON. Репозиториям выдаются URL, и для records придумывается своя URL-схема. А ещё записи подписываются криптографически, чтобы их нельзя было подделать.
Приложение на atproto работает так: нужны app server и view server, их часто объединяют в Appview. Пользователь логинится через OAuth, сообщает, где лежит его репозиторий, и даёт права на чтение и запись. Запись JSON коммитится в репозиторий, оттуда событие уходит в журнал, а затем во все view-сервисы, включая собственный. Слушать свой же event stream нужно, потому что пишут не только вы: у многих пользователей репозитории генерируют события, и другие приложения тоже пишут в них. Получается круговой поток данных: записи коммитятся в репозитории, уходят через журналы в view-серверы, и приложения их читают.
AT Protocol соединяет p2p-технологии с практиками высоконагруженных систем. Основатели Bluesky были инженерами в IPFS и Dat, а Мартин Клеппман, автор Data Intensive Applications, — технический советник. Перед запуском Bluesky поставили условие «ни шагу назад»: сеть должна быть такой же удобной и глобальной, как обычные соцсети, но оставаться открытой. Федерация и блокчейны не подходили из-за ограничений масштабирования. Поэтому взяли стандартные подходы для больших бэкендов и добавили к ним приёмы из пиринговых сетей.