如果你正在负责一个超大复杂型平台（比如电商、支付、物流）的架构师，且面临各种技术负债（比如架构复杂性、团队协同复杂性），同时业务又面临从平台服务，到场景化创新的转型。那么这篇文章也许对你有收获。
先说明下什么叫“全量在播”，指的是直播范围内，当前所有在线主播的信息，尤其是主播的房间id和uid，对于很多上游业务来说，是必要的数据，是业务逻辑的数据基础。 直播之前虽然有一套这样的系统，但是从目前运行状态看并不能面向更高体量业务支撑，而且线上也因为这种过时的在播架构工作异常发生过几次线上事故。 所以正如一本书所讲，如果不杀死任何系统，你会被僵尸包围。对于这种遗留系统需要做面向未来目标的设计。
随着应用开发变得越来越动态和复杂，交付风格一致且好用的产品成为了一项挑战，尤其是在有多个团队参与不同产品开发的大型组织中。设计系统定义了一系列的设计模式、组件库以及良好的设计和工程实践，以确保数字产品的一致性。设计系统从过去的企业风格指南演变而来，提供易于查找和使用的共享组件库和文档。通常，设计系统的风格指南以代码的形式记录并进行版本控制，比简单的文档记录更加清晰且易于维护。设计系统已经成为跨团队和学科进行产品开发时的标准方法，每当需要新的视觉组件时，团队不用重新发明轮子，因此能够集中精力，专注解决产品本身的种种挑战。 我们的经验表明，团队在构建设计系统时很少采用产品为中心的思维方式。共享组件库和文档的主要消费者是产品开发团队。在使用产品为中心的思维方式时，设计系统所有者应该与消费者（开发团队）合作，建立共情。我们发现，许多组件库之所以受到批评，是因为所有者团队无法快速响应消费者的需求，并且无法接受来自外部的贡献。产品为中心的思维方式还要求组织思考是否应该允许和怎样向设计系统做出贡献，以及如何管理这些贡献——在这个话题上，我们推荐采用设计系统决策记录 。对我们来说，维护一个良好的设计
