When imperfect systems are good: Bluesky's lossy timelines (jazco.dev)

Article summary

The article discusses the design of Bluesky's Following Feed/Timeline, which aims to balance consistency, availability, latency, and throughput. To improve performance, the system introduces a mechanism called Lossy Timelines, which reduces the correctness of a Timeline by probabilistically dropping writes to prevent hot shards. This approach allows the system to scale better and reduce latency. The implementation of Lossy Timelines has resulted in a significant reduction in hot shards and improved performance.

Main themes

• System design tradeoffs
• Scalability and performance
• Lossy timelines
• Decentralization and federation
• Social media architecture

What commenters say

• The closed-source nature of Bluesky's AppView server may limit the ability of federated servers to interact with the platform.
• The AppView is partially open-source, with some components available for public use and modification.
• Bluesky's decentralized model is questioned, with some arguing that it is not truly decentralized due to the reliance on a central relay.
• The use of Lossy Timelines is seen as a necessary tradeoff for improving performance and scalability, but may have implications for data consistency.
• Some commenters are skeptical of Bluesky's long-term viability due to its reliance on venture capital funding.
• Others argue that it is possible to use social media platforms while they are still beneficial, and then move on when they become problematic.
• The concept of a secure gossip network on top of the Bluesky API is proposed as a potential solution for creating a more decentralized and resilient network.
• The comparison between Bluesky and other decentralized social networks, such as Nostr, highlights the challenges and tradeoffs involved in designing a scalable and performant platform.