如何基于AWS设计第三方异步API操作状态轮询架构

核心采用无服务器+指数退避轮询的设计，适配1秒到1小时的异步操作时长，完全基于AWS原生服务实现，无需运维常驻资源：

1. 初始请求与状态持久化 #

• 调用第三方删除接口拿到Operation ID后，将Operation ID、关联用户标识、请求时间、当前重试次数、最大超时阈值（建议设为90分钟作为兜底）存入DynamoDB表，主键设置为Operation ID。
• 为DynamoDB表开启TTL功能，已完成的任务可设置7天后自动删除，降低存储成本。
• 同时向SQS标准队列发送一条关联该Operation ID的消息，设置初始消息延迟为1秒，覆盖最快完成的场景。

2. 轮询执行逻辑 #

使用Lambda作为SQS队列的消费者，单条消息触发一次Lambda执行，逻辑如下：

• 从消息中提取Operation ID，查询DynamoDB获取对应任务信息，调用第三方API的状态查询端点获取当前任务状态。
• 状态为completed：更新DynamoDB任务状态为完成，触发后续本地数据清理、用户通知等自定义逻辑即可，无需继续轮询。
• 状态为pending：校验当前重试次数是否触及上限（按照指数退避规则，累计间隔达到1小时约需重试10次，可根据自身需求调整），未达上限则计算下一次轮询的延迟时间：按2^重试次数计算，最高间隔不超过10分钟（低于SQS最大15分钟的消息延迟限制）。更新DynamoDB中的重试次数后，将任务重新发送到SQS队列并设置对应延迟，当前Lambda执行结束。

3. 异常与兜底处理 #

• 调用第三方API返回限流/服务错误时，将任务重新发送到SQS队列，设置30秒延迟即可，不计入正常重试次数，避免提前触发超时。
• 任务达到最大重试次数仍为pending状态时，更新DynamoDB状态为超时，推送消息到SNS主题触发告警，人工介入排查。
• 配置EventBridge定时规则，每天触发一次Lambda扫描DynamoDB中所有pending/超时状态的任务，做一次兜底校验，避免队列消息丢失、Lambda执行失败导致的漏处理。

方案优势 #

• 完全无服务器架构，无需维护常驻EC2等计算资源，仅在轮询时消耗Lambda算力，日均千级删除任务的月度成本低于1美元。
• 指数退避策略既保证短时间完成的任务能快速感知状态，也不会因频繁请求触发第三方API限流。
• 所有任务状态持久化存储，可追溯可手动修正，可靠性高。

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