我们今天就最佳解决方案进行了辩论，双方都没有达成协议。
我们有一个摄取“消息”的产品。每当我们收到新消息时，我们都需要将此数据发送到3个服务进行处理。
服务＃1要求数据采用特殊格式。为此，我们将数据放入服务读取的SQS中。
服务＃2读取消息字段：[a，b，c]，我们发送protofuf格式。
服务＃3读取消息字段：[a，b，c，d，e]，也是protobuf。
对于服务＃2和＃3，我们将数据发送到2个单独的SQS问题中。但是，我们可以在SNS主题中发送数据，队列＃2和＃3读取。为此，我们将发送服务＃3的protobuf，因为它具有所有字段服务＃2的需求。
编写服务＃2的人不想这样做，因为他不想获得他们将忽略的额外数据。
编写服务＃3的人认为，当服务＃2可以简单地读取protobuf＃3并忽略不需要的字段时，系统的资源浪费并发送到2个单独的SQS队列而不是1个SNS主题。
从架构的角度来看谁是正确的？
当您想要“通知”事件的其他服务时使用SNS - 特别是如果有多个服务可能对该事件感兴趣。
整个基于格式的区分似乎是一种人为的构造，使得使用SQS是必要的。 SQS最适合点对点通信。
从一个服务发布到2-3个位置会打开您的服务，直至原子性和可靠性问题（发布服务在发布到SQS之后但在发布到SNS之前崩溃了？）拥有一个放置消息的单一系统可以使这些问题更容易解决。
最后，它归结为您的系统所需。如果由我决定，我会更改所有下游服务以通过SNS获得通知（所有这些服务的格式一致）。
你所拥有的辩论是自以为是的观点。两种方法都需要权衡。最后，你应该努力争取长期会更好的事情（比如从现在起1年）
当SNS-SQS被认为具有高可用性时，发布到多个SQS队列并没有多大意义。我建议让一个发布者（最终数据集是相同的）和消费者方面的相同合同。
让消费者决定他们想要对数据做什么（丢弃事件;丢弃字段）。如果消费者确实不想要额外的字段，则可以实现额外的反腐败层（此ACL将位于消费者域内）。
发布者应该从他们的角度以最通用的形式发布数据。这也可以确保发布者应用程序不跨越其域。
以耦合服务为代价来优化资源将是一个非常糟糕的方法。