Atproto quer descentralizar sistemas distribuídos de grande escala

O problema da escala em redes sociais

O artigo explica a arquitetura do AT Protocol (atproto), tecnologia criada pela Bluesky para redes sociais abertas, sob a ótica de engenharia de sistemas distribuídos.

A arquitetura clássica de um backend web - um único banco de dados SQL atrás de um servidor de aplicação - atinge limites à medida que o serviço cresce. A solução passa por caches, sharding e réplicas, mas o modelo de consistência forte do SQL se torna gargalo para centenas de milhões de usuários.

A transição para processamento de fluxo

Relaxando para consistência eventual, migra-se para um cluster NoSQL (chave-valor), que escala melhor mas perde recursos como JOINs e agregações. Para compensar, constroem-se servidores de visualização (AppViews) que pré-computam e mantêm réplicas de dados em formato otimizado para leitura.

Para manter esses servidores sincronizados de forma confiável, introduz-se um log de eventos (similar ao Kafka) que registra todas as alterações e permite replay em caso de falha. Isso resulta numa arquitetura de stream-processing que escala bem, embora leituras possam ficar levemente defasadas.

Descentralizando o backend

O objetivo do atproto é quebrar o isolamento desse backend para que qualquer pessoa possa operar e consumir cada serviço. Os componentes internos - cluster de armazenamento, log de eventos, servidores de visualização - tornam-se serviços públicos com APIs abertas, e múltiplas instâncias de cada um trabalham em conjunto.

Modelo de dados unificado

Para que tudo funcione junto, define-se o repositório de dados do usuário: cada usuário possui um repositório contendo coleções de registros JSON, organizados como um key-value store ordenado. Os repositórios recebem URLs (esquema AT URI) e os registros são assinados criptograficamente para garantir autenticidade mesmo quando hospedados por terceiros.

Fluxo de dados na prática

O ciclo funciona assim:

1. O usuário autentica via OAuth e indica qual servidor hospeda seu repositório.
2. Gravações (ex.: um post) são confirmadas no repositório.
3. O repositório emite o evento para logs de eventos.
4. Os logs distribuem o evento para todos os AppViews que estão ouvindo.
5. Os AppViews indexam o dado e o disponibilizam para leitura pelos aplicativos.

Esse fluxo circular permite que múltiplos aplicativos leiam e escrevam nos mesmos repositórios, criando uma rede aberta e compartilhada.

Filosofia de design

Os engenheiros fundadores vieram do IPFS e do Dat, e Martin Kleppmann (autor de Designing Data-Intensive Applications) é consultor técnico ativo. O requisito central foi "nenhum passo para trás": a rede deveria ser tão conveniente e global quanto serviços sociais centralizados, mas funcionando como rede aberta. Por isso, em vez de adotar federação tradicional ou blockchain - que têm limites de escala -, o atproto combina práticas de backends de alta escala com técnicas de sistemas peer-to-peer.