LinkedIn消息平台现在存储了价值17年的消息（使用17年的不同产品功能创建），并且发送的消息数量一直保持不变往上走。
最初，这些消息看起来很像电子邮件。现在，他们看起来更像是聊天，带有主题，群组对话，表情符号，没有主题行。支持该消息传递系统的代码已经过更新，变得越来越复杂，但是多年来，支持所有不同的LinkedIn消息传递体验的通用基础结构并未发生太大变化。
原始基础架构是一个单一的Oracle数据库，在一个数据中心中运行，有两个表为两项服务提供动力：一个用于存储消息，其中包括用于多个LinkedIn产品的消息的所有业务逻辑，以及一个负责不同方法的消息。可以传递邮件-推送通知，不同的电子邮件格式以及跟踪它们的接收情况。
随着时间的推移，LinkedIn添加了新的数据中心，并使用其自己的NoSQL JSON数据库Espresso切换到具有分片架构的分布式数据存储。向外扩展带来了自己的复杂性。使用个人数据路由服务在各个分片之间划分不同的消息邮箱，以跟踪其消息收件箱位于哪个分片上，并进行双向复制，以在出现可用性问题时将每个分片的副本放入不同的数据中心。
当任何LinkedIn产品团队想要向消息传递中添加功能（有时为其编写代码或与他们合作进行开发）时，基础结构团队都会参与其中，并负责维护生产中的所有新代码。所有这些业务用例都存在于一个单独的代码库中，由消息团队负责长期维护。
随着公司的发展，随着我们在17年内增加了更多的业务范围，用例变得越来越复杂，用例也越来越多，大约有六十种不同的自定义业务逻辑。这对于我们的工程师来说确实很难。没有人能完全理解平台中发生的每个业务用例。
开发人员对最简单的更改过于谨慎，因为越来越多的团队时间都花在了保持运行上。维护成本消耗了大部分工程时间。
解决办法
在在基础结构和产品团队之间重新分配服务所有权。分解消息内容，让可以共享的内容共享，然后将不需要共享的内容隔离到一个服务中，然后围绕责任归属设计我们的系统，然后提供这些服务的数据成为后面数据库的责任。
消息传递的基本单元不再是整个收件箱，而是会话，这使得传递快速的搜索和检索时间变得更加容易，因为会话和消息可以分解并分布在整个数据库中。会话与消息分开存储，并带有对消息的引用，以避免非常活跃的数据库记录出现“热key”问题，这些问题可能会使系统变慢。
现在，无法直接从消息列表中获取某个消息，只能获取会话列表，只有访问了其中一个会话，才可以访问其中的消息。
产品团队仍与基础架构团队一起工作，但是所有自定义业务逻辑已从消息存储中移出并封装到插件中以实现其功能，并且不同的服务所有者可以在需要帮助时与他们一起工作。
更详细点击标题见原文