事件存储区只不过是一个事件日志，它被完全重放以重新生成服务的原始状态。如果在kafka中使用压缩主题，则可以最小化还原时间（压缩主题只会删除同一密钥的旧事件）。这对于运行时状态很好。
有许多选项可用于促进查询。如果您不介意深入了解整个kstreams，最简单的方法就是在ktable或state存储中实现可查询视图。这是一个数据库（它在幕后使用rocksdb）构建在您的服务中。它充当备份日志中数据的磁盘备份缓存。这有一个有用的特性，即支持流可以由许多服务共享，但物化视图完全由每个服务拥有。
一般来说，一个好的方法是做最简单的事情，然后进行改进。尝试保持服务无状态和事件驱动。如果您的需求需要有状态元素，请拉入ktable或states存储。如果您的数据需求增长，可以考虑扩展到一个独立的数据库。如果您从一个kafka支持的存储开始，那么通常可以使用connectapi相对容易地迁移数据（尽管您的逻辑可能会受到影响）。
对于这种类型的实现，一个值得注意的技巧是避免在服务之间合成请求-响应通道。取而代之的是遵循事件驱动的体系结构，在这种体系结构中，您可以构建事件的共享叙述。马丁·福勒不久前就写了一篇很好的文章。他称之为事件协作。

我不建议构建一个必须在没有任何永久存储的情况下保存数据的应用程序。即使可以永远存储事件队列，但对于随机数据访问来说也不是很好。假设您的应用程序需要访问存储在队列中间的一些用户信息。由于您没有事件id，因此必须重新处理队列才能找到非常慢的信息。
事件队列有助于解耦服务依赖关系，但它不是一个好的永久数据存储。通常，您需要使用依赖于服务的使用者来处理队列，这些使用者将数据转换并移动到对服务有用的格式和存储中。
也可以看到这个答案