在我的公司，我们使用Event Sourcing模式来实现预订价格的所有更改的存储。在整个公司，不同的服务可能会尝试将事件附加到由预订代码标识的预订。
我们使用DynamoDB来存储事件，它支持一致性读取。事情是这样的，当最初进行预订并且为预订代码创建了第一个事件时，如果由于某种原因我们未能将事件保存到DynamoDB中，我们将事件放入回退队列并简单地向客户端返回成功，以确认我们已经收到了事件。然后，客户端可以继续执行其业务逻辑流，并依次向最终用户显示成功消息。目标是不不惜一切代价阻止预订创建。
问题是，在很短的一段时间内，当事件仍在回退队列中时，如果客户端试图使用预订代码获取事件，尽管我们告诉他们第一个事件的写入是成功的，但他们将返回一个错误。在某种程度上，我们在这里违反了一致读的承诺。
我正试图找到一种方法，我们可以改进设计，保持这一承诺，同时不妨碍主要预订流程(即不阻止预订失败)。
,我会非常感激的,如果有人能把我的想法看。
一个解决方案可能是让后备队列是持久的(即从它读取不会从队列中删除元素)，直到一定的保留期(广义地说:从初始预订到将创建事件持久化到DynamoDB之间的最大允许时间)，而不是作为后备队列作为已创建预订的实际事实来源。
服务可以使用这个队列:其中一个服务负责将初始创建事件写入DynamoDB(它的生存时间比队列长)。如果该服务落后并接近保留限制，这是一个操作紧急情况，但你是在为自己争取时间。这些服务中的另一个维护一个内存视图，该视图基于已创建的预订队列，这些预订尚未进入Dynamo。