我们目前在一个消息驱动的微服务环境中工作，我们的一些消息/事件是事件源的（使用apachekafka）。现在我们正在努力实现更复杂的业务需求，因为我们必须考虑多个事件来创建新的事件和副作用。
在目前的情况下，我们使用的是可能产生错误的设备，我们已经对它们进行了处理，并且有一个单独的主题，其中包含错误\发生和错误\解决的事件（因此它们是有序的）。我们还要确保，所有关于特定设备的消息总是放在同一个分区上。两条消息共享一个标识特定错误事件的id。我们已经有了一个使用这些事件的投影，并为我们的客户s.t.提供了一个api。他们可以看到所有发生的错误及其当前状态。
现在我们必须处理以下要求：

报告错误

我们需要一个推送系统，向外部合作伙伴报告设备的错误，但只能在15分钟后，如果在该时间段内没有解决这些问题。我们的第一种方法是使用所有error\u解析的事件，存储id，并让另一个使用者以延迟的方式处理error\u occurrend事件（例如，如果主题的时间戳至少为15分钟，则只使用主题上的下一个error\u occurrend事件）。然后我们就可以知道这个特定的错误是否已经被解决，并且不需要报告（因为它们与相应的error\u resolved事件共享一个公共id）。否则，我们将向外部合作伙伴发送http请求，并在新主题上创建错误报告事件。对于延迟和有条件的消息处理，有没有更好的方法？
我们还必须考虑以下特殊用例：
服务重新启动：目前我们计划将已解决错误的列表保留在内存中，因此如果服务重新启动，则必须从头开始创建该列表。我们可以只重播已解决的错误消息，但这可能需要一些时间，在这段时间内不应处理任何已发生的错误事件，因为这可能会导致报告已在不到15分钟内解决的错误，但我们只是没有意识到这一点。关于重播和“正常”处理有什么好的做法吗？
缩放：我们可以随时增加或减少服务的示例数，因此分区分配可能在运行时发生变化。如果我们在使用error\u resolved events s s.t.时为每个服务示例创建一个使用者组，那么这应该不是问题。每个示例都知道所有已解决的错误，但仍然只处理其分配分区（在由所有示例共享的另一个使用者组中）的error\u occurred events。有没有更好的方法来处理分区重新分配和内部状态？
提前谢谢！