AT Protocol lays out how its decentralized backend scales
The walkthrough starts with a classic web backend: one app server talking to a single SQL database. As traffic grows, the article adds caches, then horizontal sharding and replicas to the database. It argues that even this setup scales only so far for a social network with hundreds of millions of users, a hypothetical illustration used to make the point, not a claim about Bluesky's actual user count, because a strongly consistent SQL database has to keep state uniformly in sync, which caps throughput.
To scale further, the walkthrough relaxes consistency: it moves to an eventually consistent NoSQL key-value cluster, which is fast but lacks SQL's joins and aggregation queries. To compensate, it introduces "view servers" that hold precomputed, denormalized views of the data, kept in sync through an event log; the article names Kafka only as an illustrative example of that kind of log within its hypothetical walkthrough, not as a statement of what AT Protocol runs in production. Together the NoSQL cluster, the view servers and the event log form a stream-processing architecture that trades strong consistency, reads can lag behind the latest writes, for horizontal scale without dropping writes or entering an incorrect state.
AT Protocol's move, according to the article, is to take every internal piece of that architecture, the NoSQL store, the event log, the view servers, and expose each as a public service that anyone can run their own instance of, so that many independent operators' services interoperate rather than one company running all of them. To make that interoperation possible, it defines a shared data model: each user has a "data repository" containing JSON documents called records, grouped into collections; each collection is an ordered key/value store. Repositories and records are given URLs, and records are cryptographically signed so a copy can be verified as authentic no matter who is hosting or relaying it.
On top of that model, a typical AT Protocol app pairs an "app server" (API and frontend) with a "view server" that collects data from the network; the article calls the combination an "Appview." A user authenticates through OAuth and grants the app read and write access to whichever server hosts their data repository. A write commits a JSON document to that repository, which fires an event into the logs listening to it; that event propagates to any view services subscribed to it, including the writing app's own view server, since other apps and other users' repositories are producing events at the same time. The result, per the article, is a circular flow: writes land in repositories, get emitted through event logs, and get read back out of view servers by applications.
The article frames the overall design as merging peer-to-peer technology with high-scale backend engineering practice. It says AT Protocol's founding engineers came from IPFS and Dat, without naming any of them individually, and that Martin Kleppmann, author of "Data Intensive Applications," is an active technical advisor. Before building Bluesky, the team set a "no steps backwards" requirement: the network should feel as convenient and global as any existing social app while still operating as an open network. It says that when the team looked at federation and blockchain designs, without specifying which systems, the scaling limits of those approaches stood out, so instead of adopting either wholesale it applied standard high-scale backend techniques together with peer-to-peer methods.
Key facts
- The article traces a classic SQL backend hitting scaling limits (single database, then caches, then sharding and replicas) and the resulting shift to an eventually consistent NoSQL cluster plus precomputed "view servers" kept in sync by an event log, a stream-processing architecture AT Protocol builds on.
- AT Protocol's design opens each internal service, the NoSQL data store, the event log, the view servers, into public, independently operated components, unified around a "user data repository" made of collections of JSON records that carry URLs and cryptographic signatures.
- A typical app pairs an app server with a view server, called an "Appview"; users authenticate with OAuth to grant read/write access to wherever their data repository is hosted, and writes flow from repository commit through the event log to every subscribed view server, including the writing app's own.
- The article credits AT Protocol's founding engineers as coming from IPFS and Dat, and names Martin Kleppmann, author of "Data Intensive Applications," as an active technical advisor.
- Before building Bluesky, the team set a "no steps backwards" requirement, keeping the network as convenient as existing social apps while staying open, after concluding that federation and blockchain designs both run into scaling limits.
Why it matters
The piece is a direct explanation, from AT Protocol's own team, of the engineering reasoning behind Bluesky's decentralized backend: rather than treating decentralization as a separate discipline, it presents AT Protocol as an application of ordinary high-scale backend patterns, precomputed view servers fed by an event log, to a network where those services are run by many independent operators instead of one company. That framing matters to anyone deciding whether a federated or blockchain-based design, the two alternatives the article says it weighed, can scale the way a large centralized service does.
Who it affects
The explainer targets distributed-systems engineers evaluating or building on AT Protocol, and engineers designing any federated or open network who want a concrete, familiar reference architecture. It is also relevant to anyone building an app on top of an AT Protocol data repository, since the article's "Appview" pattern, an app server paired with a view server, describes exactly what happens to a write from the moment it is committed to when it reaches other applications.
How to use it
The article names no price, license or product tier; it is a technical explainer, not a product announcement. The practical takeaway for someone building on AT Protocol is architectural: give each user a data repository of JSON records grouped into collections, address repositories and records with URLs, sign records cryptographically, and build an Appview that reads and writes through an event log rather than talking to storage directly, so that its own view stays consistent with the state of the shared network.
How solid is it
The account comes directly from atproto.com and describes AT Protocol's own design rationale, with one on-record credential: Martin Kleppmann, author of "Data Intensive Applications," is named as an active technical advisor. The article carries no publication date or byline, and it cites no production numbers, real user counts, latency or throughput, for the live network; the "hundreds of millions of users" figure and the mention of Kafka both appear only inside an illustrative, hypothetical walkthrough of a generic backend, not as claims about what AT Protocol currently runs.
Risks and caveats
The comparison with federation and blockchain systems is asserted rather than shown: the article says their scaling limits "stood out" without naming which specific systems it evaluated or what limits it measured. Beyond Kleppmann, no other founding engineers are named, only that they came from IPFS and Dat. Readers should treat this as the protocol team's own architectural narrative rather than an independent benchmark of AT Protocol against its alternatives.
“We established a clear requirement of "no steps backwards."”
— AT Protocol article, on the requirement set before building Bluesky