主要观点：系统设计常追求各方面完美，但难以同时实现，需平衡各属性。以 Bluesky 为例，在设计 Following Feed/Timeline 时做了权衡以提升写入性能，减少 P99 达 96%。
关键信息：

• 系统设计难以兼顾一致性、可用性等，需平衡各属性。
• Bluesky 的 Timeline Fanout 过程，包括索引、分发等，且按用户分片。
• 大量用户异常行为会导致“Hot Shard”，影响系统性能。
• 考虑尾延迟，并发 Fanout 虽快但受慢写影响大，最坏情况 Fanout 可能长达 5 分钟。
• 引入“Lossy Timelines”机制，通过设定合理限制和损失因子，减少单个 Timeline 对数据库分片的工作，改善系统性能。
• 实现缓存高关注账户，提升 Fanout 服务性能。
  重要细节：
• Bluesky 约有 3200 万用户，Timeline 数据库分数百片，用户 Timeline 分区常与其他用户共置。
• 平均写延迟约 600 微秒，P99 延迟可达 15 毫秒，慢写会影响后续 Fanout 页面。
• 设定“reasonable limit”，如 2000，超过该限制的用户损失因子降低，写入到 Timeline 的概率减少。
• 实施 Lossy Timelines 后，Timelines 数据库集群无热分片，单页 Fanout P99 降低超 90%，全 Post Fanout P99 降低超 96%。