我正在为一个网站设计后端，该网站使用API网关和Lambda来处理API请求，其中许多请求针对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，将更改读取为某个表中的新行，并发送电子邮件。
选项1:
- 更少的基础设施
- 更直接地跟踪API调用中的逻辑
- 1个额外的http调用(到sqs(延迟网页api的响应时间
选项2:
- 更多基础架构(dms任务、复制实例(
- 如果排序是必需的，那么在处理binlog事件时，扩展碎片可能意味着失去排序(确实如此(
- 附带问题：你能从mysql中为dms任务选择kinesis的哈希密钥吗
- 用于对DB中的所有修改作出反应的单个代码库实际上可以使代码中的以下逻辑更简单
这是权衡还是我遗漏了什么？这种情况下的最佳实践是什么？
在我看来，选项1似乎最符合逻辑，但我会用SNS替换SQS和第二个lambda。因此，修改后的选项1可以是：
选项1：在处理API请求的lambda中，首先写入MySQL实例以添加新行。当MySQL的响应成功返回时，将确认消息发布到发送电子邮件的SNS。当SNS的响应成功时，发送201响应，表示REST API调用成功。
这应该比使用SQS和第二个lambda发送电子邮件更快、更便宜、更容易实现。