AWS Lambda超时后Dynamo写入事务是否会自动回滚？

Lambda函数触发超时后，已经执行完成的DynamoDB写入操作不会自动回滚。Lambda和DynamoDB是完全独立的两个服务，Lambda执行超时本质是运行环境把函数进程强制终止，这个动作不会反向撤销已经提交到DynamoDB、并执行完成的事务操作，不存在自动回滚的机制。

两类提到的操作场景实际行为 #

• 逐一对单个数据项执行事务更新：单条记录的事务一旦提交成功，写入就永久生效。如果函数在后续条目处理时超时，之前所有提交成功的单条写入都会保留，不会回滚。
• 按25条分片执行批量事务更新：DynamoDB原生TransactWriteItems保证单个批次（最多25条操作）的原子性，即单批次要么全成功要么全失败，但只要某一批次提交成功，这25条数据就会持久化生效。如果后续批次处理时函数超时，之前提交成功的所有批次数据都不会自动撤销。

100条记录更新到第99条超时的全量回滚落地方案 #

首先明确一个避坑点：别指望靠监听Lambda超时信号写回滚逻辑，超时触发后函数剩余可执行时间通常只有几百毫秒，根本跑不完近百条记录的回滚操作，生产环境下这类方案可靠性为0。要实现全量更新要么全成要么全回滚，直接从架构上避免部分提交的中间态即可，常用方案有三个：

• 方案1：全量条目放入同一个原生事务提交
  DynamoDB的TransactWriteItems接口单次最多支持100个操作条目、总负载不超过4MB，刚好匹配你100条记录的更新规模。直接把100条更新全部放到同一个事务请求中提交即可，这个事务本身具备全原子性：不存在99条成功1条失败的中间态，要么100条全部更新成功，要么全部失败，从根源上绕开了超时导致的部分写入问题。
• 方案2：超规模场景用Saga补偿事务实现最终一致
  如果后续更新规模超过单事务100条/4MB的限制，就不要边处理边提交真实业务更新，走事务日志+补偿逻辑：
  1. 新建一张独立的事务日志表，更新开始前先把所有待更新记录的主键、原始值、事务状态（初始化为「进行中」）写入日志表，日志写成功后再开始分片批量更新。
  2. 每完成一个分片的批量更新，就同步更新日志表中对应条目的状态为「已提交」。
  3. 每次Lambda函数冷启动/定时触发巡检任务时，扫描日志表中状态为「进行中」、且最后更新时间超过函数最大超时配置2倍的未完成事务，针对这类中断的事务，按照日志里记录的原始值，把已经提交的分片数据全部改回原始值，最后把事务状态标记为「已回滚」。
     所有更新和回滚操作都要加条件写入做幂等校验，避免重复执行导致数据错乱。
• 方案3：版本化指针切换实现无锁原子更新
  给业务数据增加data_version字段做版本标识，全量更新时不要直接修改线上正在使用的当前版本数据，而是把100条更新全部写入新版本对应的分区下，等所有记录更新完成、校验通过后，用一条单独的原子更新操作，把全局版本指针切到新版本号。整个更新过程中如果Lambda超时，因为新版本数据还没被版本指针指向，根本不会被业务读取到，直接废弃即可，不需要做任何回滚操作，旧版本线上数据完全不受影响。

额外提醒：如果你的函数内存配置比较低，DynamoDB客户端的SDK重试逻辑也可能拉长整体执行时间，建议提前根据压测结果调整Lambda超时配置和SDK重试次数，尽量从执行侧减少超时触发概率。

内容的提问来源于stack exchange，提问作者user1555190