Bluesky looks and scrolls just like Twitter, but underneath, your posts don't live in one company's database. They live in your own Personal Data Server, signed with your keys. The point is portability: you can move to a different server later and keep your handle and all your followers. The hard part is making a normal-feeling social network on top of storage that is spread across many independent servers.

Here is how it holds together. When you post, the record is written to your own PDS. Your PDS then streams that event to a Relay, which subscribes to every PDS in the network and merges them all into one public firehose of 'every event that just happened.' Read-side services called AppViews subscribe to that firehose, build a precomputed timeline index for each user, and answer your client's request for a home feed in under 100ms.

The reason the Relay exists is worth a simple picture. Without it, every feed builder and search index would have to keep a live connection to every single PDS, which is a tangled N times M mess. The Relay is like a newswire: thousands of reporters file to one wire service, and any newspaper subscribes to that single wire instead of calling every reporter. It turns an N times M problem into N plus M.

There is one more layer of indirection that makes portability work. You follow people by their DID, a stable decentralized identifier, not by their server address. A DID Resolver maps that DID to whichever PDS currently hosts them, so when someone migrates servers, your follow doesn't break. The cost of all this decentralization shows up at read time: hydrating a timeline can mean fetching post content back from many different PDSes, which AppView caches paper over until the cache goes cold.

This system teaches federation versus centralization, the PDS-Relay-AppView split, why a fan-out reducer like the Relay is necessary, identity indirection through stable DIDs for account portability, and the fundamental tradeoff of paying read-time fan-out to buy write-time data ownership.