我们有一个简单的应用程序，每次更新实体时都会向SNS发送通知(很可能是任何其他排队系统(。客户端正在侦听这些通知，并根据这些通知获取更新的实体。
我们面临的问题是，当客户端执行 get 时，有时数据不会被复制，我们返回 404 或有时是过时的数据(甚至更糟(。
我们如何在发送通知时缓解此问题？
这里有一些策略可以缓解这种情况，有利有弊
-
不是从应用程序发送通知，而是使用数据库流发送通知
例如dynamodb streams ans aws lambda。此模式在多区域部署的情况下也很有用。其中所有订阅者、发布者将订阅其区域数据库流。并且还保留了发送消息和写入数据库的原子性。在地区失败的情况下，我们不会失去事件。
-
向您的代理发送延迟消息
一些像activemq和sqs这样的borker支持此功能，但SNS不支持。解决方法可能是写入 sqs 队列，然后写入 sns。当您的数据库不支持流时，这可能是一个不错的选择。
-
发送特殊错误代码以进行可重试的获取
由于我们知道存在最终一致性，因此我们可以向客户端返回特殊的错误代码，以便它们可以根据此错误代码重试。重试策略应该是指数退避。但这可能意味着把你的问题交给客户。此外，我们应该有某种版本控制。
-
从其他区域提取
如果在同一区域中找不到实体，应用程序可以转到另一个区域或 master 数据库来获取它。注意别这样。因为它是一种反模式。我在这里提到它只是为了完成。
-
在消息中发送完整实体
如果 rest 服务要获取的实体很小，并且对谁可以访问什么没有安全约束，我们可以在消息中发送完整的实体。这是为了确保客户端不必在每次到达新消息时都显式获取它。