为什么还要将它们写入 SQS？最初的计划是将 webhook 正文写入 DynamoDB，并只向 SQS 写入一条指向主键的消息。然而，在计算了支持此功能所需的 DynamoDB 写入吞吐量的成本后，我们选择继续发布到 SQS 并丢弃不再需要处理的消息。
另一个反对将整个正文发布到 DynamoDB 的因素是，有 德国号码数据 些平台只发送项目 ID 的变化，而其他平台则发送项目的完整正文。这可能会导致多兆字节的正文大于 DynamoDB 的最大项目大小 400K。
多兆字节的正文 webhook 也给 SQS 带来了问题
因为 SQS 的最大消息大小为 256K。我们收到的这种大型钩子并不多（不到 0.02%），因此我们将正文精简到最基本的要素（ID 和一些元数据），并向下游处理器发出信号，告知它们需要直接从平台备份此项目。
这是聚合 webhook 的主要架构。不过，我们还发现了一些其他非常重要的好处。让我们来看看这些好处。
变化 3 – Lambda 优化
我们希望在 Lambda 函数中尽快处理所有 webhook，这既 餐食套件公司The Good Kitchen提供自建订阅盒体验 是为了节省成本，也是为了我们能够及时响应生成钩子的平台。
参数存储
我们的函数需要一些存储在 AWS 参数存储中的机密。每次 WhatsApp 号码 执行函数时都访问参数存储不仅耗时而且成本高昂。因此，我们使用了常见的 Lambda 最佳实践，在 Lambda 处理程序之外检索机密，并将它们缓存在执行环境的内存中。