我正在实现一个聊天应用程序，它将支持一对一对话和小组对话。
到目前为止，发展方向是使用redispub/sub和postgresql作为冷库，websocket作为传输工具。每个用户在启动时都会从postgresql获取历史（直到websocket+redis连接的时间戳），然后根据自己的用户id订阅频道。
然而，每一条新消息都有一次到dmbs的往返，听起来有点奇怪，但绝对是可行和合法的。所以我决定研究其他方法。一种可能的方法是使用kafka，完全不需要dbms。这听起来是可行的，而且有自己的一套优势。
结果发现街区里有个新来的孩子——redis streams。
据我所知，在这个特定场景（聊天）中，它实际上与Kafka非常相似。它有许多很好的特性，听起来非常方便实现聊天系统。
现在，我正试图理解，与kafka和postgresql+redis pub/sub相比，streams+disk持久性是否是明智的选择
考虑的主要方面有：
性能。postgres和kafka都在磁盘上运行，这意味着比redis的内存操作要慢。另一方面，显然消息必须在任何时间和事件中都被持久化和可用，因此redis将被持久化到磁盘。这难道不会抵消内存性能的整体提升吗？即使不是这样，在峰值负载和大数据库下的性能提升是否值得注意？
内存/成本。有了redis，这两者紧密联系在一起。作为一家小型初创公司，我们的工作重点是准备好应对突然出现的规模高峰（高达100万用户），但与此同时，成本应该降到最低。在流中存储数百万条消息是否会导致内存开销过大，进而导致财务开销？
恢复、可靠性和可用性、持久性。使用postgres，即使是一个示例也可以处理大量的流量负载，但它也可以提供主从设置和一致性。redis能与之匹配吗？而且，有了dmbs，我可以确信数据会留在那里。我能跟redis一起知道吗？
缩放比例。