如何为DynamoDB Stream触发的Lambda配置可自定义的重试延迟

Lambda原生的DynamoDB Stream触发器不支持直接配置重试前的延迟，SQS的redrive policy能力也不适用于DynamoDB Stream的原生触发场景。你可以参考以下几种符合你需求的落地方案：

方案1：新增SQS缓冲层（完全匹配你需要的重试控制能力） #

调整现有调用链路为：

dynamodb streams => 
  轻量投递Lambda（仅做消息转发到SQS，无业务逻辑） => 
  SQS队列（配置自定义redrive policy、重试延迟） =>
  业务处理Lambda =>
  写入下游服务

• 该方案可以直接复用SQS的重试控制能力，自定义调整重试间隔、最大重试次数，完全匹配你对重试速率的控制需求
• 轻量投递Lambda的执行时长通常在10ms以内，额外产生的成本几乎可以忽略，完全避免了在业务Lambda内休眠产生的不必要计费
• 可以搭配SQS的可见性超时、死信队列配置，灵活适配不同的峰值处理、异常兜底需求

方案2：不改动现有链路的折衷配置 #

如果不想调整现有链路结构，可以通过以下触发器配置缓解429问题：

• 降低DynamoDB Stream触发器的批次大小，减少单次Lambda调用需要向下游写入的数据量
• 调小Lambda的预留并发数，从源头上控制下游的并发请求量
  你提到DynamoDB Stream本身可作为缓冲应对偶发瞬时峰值，该配置产生的短暂堆积完全可以在峰值过去后自动追平，不会影响数据最终一致性。

方案3：轻量代码级重试优化 #

如果既不想改链路也不想调整并发配置，可以把全链路指数退避改为轻量快速重试：
仅在首次收到下游429状态码时，做1-2次短间隔（比如100ms）的重试，仍失败就直接抛出异常触发Lambda原生重试。由于DynamoDB Stream的重试是分片串行的，单条消息处理失败后，同分片的后续消息都会被阻塞，直到当前消息处理成功或进入死信队列，相当于天然存在重试间隔，不会产生大量重复瞬时请求。

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