如何确保AWS SES事件的顺序正确性？

首先明确一个关键点：AWS SES本身是按照事件实际发生的时间顺序来发布通知的，比如先触发Send事件，再触发Delivery事件。但问题出在下游的SNS和SQS环节——标准SNS/SQS都是「尽力而为」的投递模式，不保证消息的严格顺序，尤其是当网络波动、服务重试或者消息路由出现延迟时，就会出现你遇到的“Delivery比Send先到”的情况。

下面给你几个AWS侧的解决方案，按落地难度和实用性排序：

方案1：在Lambda端做顺序校验与状态幂等处理（最易落地） #

这是最直接的补救方式，不需要改动上游架构，只需要在处理事件的Lambda里加一层逻辑：

• 每个SES事件里都包含mail.messageId（唯一标识一封邮件）和timestamp（事件发生的UTC时间戳），还有事件类型（Send/Delivery/Bounce等）。
• 对接一个轻量存储（比如DynamoDB），为每个messageId维护一条记录，存储当前已处理的最新事件时间戳和系统状态。
• 当Lambda收到新事件时，先去DynamoDB查询该messageId的最新记录：
  • 如果新事件的timestamp早于已存储的最新时间戳，说明这是一个“迟到”的旧事件，直接忽略即可；
  • 如果新事件的timestamp晚于已存储的时间戳，就更新系统状态，并同步更新DynamoDB里的记录。
• 可以给DynamoDB的记录设置TTL（生存时间），比如7天，自动清理旧邮件的状态记录，避免存储冗余。

方案2：用Kinesis Data Streams替代SNS+SQS，保证分区内顺序 #

如果你的邮件量较大，且对顺序要求严格，可以调整架构，利用Kinesis的分区顺序特性：

• 因为SES配置集不支持直接投递到FIFO SNS，但可以先把事件投递到一个轻量转发Lambda（只做消息透传，不处理业务逻辑）；
• 转发Lambda收到SES事件后，将事件推送到Kinesis Data Streams，并且用mail.messageId作为分区键——这样同一封邮件的所有事件都会进入同一个Kinesis分区；
• 最后用消费Lambda从Kinesis读取消息，因为Kinesis保证同一个分区内的消息是严格按顺序投递的，所以消费Lambda可以按顺序处理事件并同步到你的系统。
• 这种方案既能保证顺序，又能支持高吞吐量，适合邮件量较大的场景。

方案3：优化现有SQS+Lambda的并发与处理逻辑（适合小流量场景） #

如果不想大改架构，可以尝试调整SQS和Lambda的配置：

• 给SQS设置合理的可见性超时（比如30秒），确保同一个messageId的消息不会被多个Lambda实例同时处理；
• 限制该队列对应的Lambda并发数为1——这样Lambda会按消息进入队列的顺序逐一处理，但缺点是会严重影响吞吐量，只适合邮件量很小的场景；
• 另外，可以在Lambda里做短暂的消息暂存：比如用内存缓存（或DynamoDB）收集同一个messageId的事件，等待1~2分钟后，按timestamp排序再批量处理，这样能大概率覆盖延迟的旧事件，但会引入处理延迟，需要根据业务场景权衡。

最后再确认下你关心的点：SES确实会按事件发生的先后顺序发布通知，但下游的标准SNS/SQS无法保证投递顺序，所以必须在下游环节做顺序校验或者引入顺序保障的服务。

备注：内容来源于stack exchange，提问作者Otrozone