我应该如何处理AWS中API调用后发生的异步进程？

Question

我正在为一个网站设计后端，该网站使用应用编程接口网关和Lambda来处理应用编程接口请求，其中许多请求针对RDS上的MySQL数据库。有些过程需要异步进行，但我正在争论哪个是最佳实践还是更干净。

在给定的场景中，每次用户在某个表中创建新行时，都需要异步发送电子邮件。还有许多其他类似的情况，但这将成为先例。

选项1：在处理API请求的lambda中，首先写入MySQL实例以添加新行。当来自MySQL的响应成功返回时，写入类似SQS的内容，稍后将从另一个发送电子邮件的lambda读取该内容。当来自SQS的响应成功地将记录添加到队列中时，发送201响应，说明REST API调用成功。

选项2：在处理API请求的lambda中，写入MySQL实例以添加新行。当来自MySQL的响应成功返回时，发送201响应，说明REST API调用成功。然后设置一个无限期运行的DMS（数据迁移服务）任务，将数据库修改Binlog发送到一个kinesis流，该流将触发一个lambda，该lambda将处理所有DB更改，将更改读取为某个表中的新行，并发送电子邮件。

选项1：

• 更少的基础设施
• 更直接地跟踪来自API调用的逻辑
• 1个额外的http调用（对sqs）延迟网页api的响应时间

选项2：

• 更多基础架构（dms任务、复制实例）
• 如果需要排序，则在处理binlog事件时，缩小碎片可能意味着失去排序
  • 附带问题：您能够从mysql中为dms任务的kinesis选择哈希键吗

  这是权衡还是我遗漏了什么？这种情况下的最佳做法是什么？

Answer 1

在我看来，选项1似乎最符合逻辑，但我会用SNS替换SQS和第二个lambda。因此，修改后的选项1可以是：

选项1：在处理API请求的lambda中，首先写入MySQL实例以添加新行。当MySQL的响应成功返回时，向发送电子邮件的SNS发布确认消息。当来自SNS的响应成功时，发送201响应，表示REST API调用成功。

这应该比使用SQS和second lambda发送电子邮件更快、更便宜、更容易实现。