tldr：具有请求/响应模式。当前请求通过activemq队列完成，响应通过memcached键值存储（由前端轮询）完成。出于各种原因，我们想迁移到Kafka，想知道我们是否可以重新设计响应路径，不使用memcached。
我试图了解什么将是最佳实践系统设计以下问题。
我们有一个前端，它生成需要大量处理的请求。应用程序需要响应才能前进。有时我们需要撤消/后退（这会使您恢复到以前的状态）。有一组后端可以执行繁重的处理步骤。
在我们当前的设置中，前端将请求推入队列（当前为activemq），后端尽可能地处理队列中的项目，并将结果存储在键值存储（memcached）中，键值是队列中消息的uuid（它本身是唯一的会话id+非唯一的步骤id）。前端正在轮询存储以获取消息的uuid。这样做的好处是前端可能会失去连接/etc，但只要会话id被保留，我们就可以ping键值存储以获得所需的结果。我们有时还需要向后移动/撤消操作，并且可以在键值存储中返回结果（因为每个步骤都有自己的uuid，并且所有uuid都是已知的）。
但是，将来我们希望能够至少部分地通过队列进行响应，这样我们就可以拥有一些分析工具作为请求和响应的消费者。“最小的改变”是将响应生产者推入一个队列，并将memcached作为消费者之一。但也许有更好的办法。我们也在考虑从activemq切换到kafka，因为这将给我们提供可重放性（但我们没有kafka的经验）。
在kafka看来，要得到一条特定的消息，您需要扫描整个分区，有没有更简单的方法来检索特定的消息？我们是否为每个交互序列生成一个主题？如果我们想重播，但不知道补偿什么是我们的资源（除了看了很多消息）？我们的负载非常小（约1百万条消息/天），所以我想除了什么是最佳实践（臭名昭著的，如果我们扩展怎么办）？