基于SQS队列的事件驱动架构API集成方案优化咨询

一、支付流程优化 #

• DocumentDB数据自动清理：仅依赖Payment API显式删除暂存数据存在风险，若Payment API处理异常崩溃，会导致数据永久堆积。建议给DocumentDB中的支付数据文档配置TTL（生存时间），设置为24小时（远超遗留DB最长15分钟的处理耗时），作为兜底清理机制。
• SQS消息可靠性强化：
  • 配置死信队列（DLQ）：当Payment API对同一条消息重试超过3次仍失败时，自动将消息转入DLQ，避免无效重试占用资源，同时便于后续人工排查失败原因。
  • 调整可见性超时：将SQS消息的可见性超时设置为20分钟，确保Payment API在处理遗留DB请求的过程中，消息不会被重新分发导致重复处理。
• 支付状态查询能力：新增支付状态查询接口（可挂在Integrator API或独立服务下），在DocumentDB中维护支付状态字段（待处理/处理中/成功/失败），Payment API完成处理后实时更新状态，方便上游服务或前端按需查询。

二、Invoice API对接优化 #

• 异步解耦Invoice调用：当前Payment API直接调用Invoice API，若Invoice API临时故障，会导致发票生成逻辑失败。建议在两者之间引入SQS队列，Payment API处理完成后仅发送发票生成元数据到队列，由独立的消费者服务（如Invoice Processor）负责调用Invoice API。即使Invoice API不可用，请求也不会丢失，后续可自动重试。
• 后置处理逻辑解耦：若后置处理逻辑未来可能被其他流程复用，建议将其抽取为独立的微服务或无服务器函数（如AWS Lambda），而非完全耦合在Payment API中，遵循单一职责原则，降低维护成本。

三、整体架构补充项 #

• 全链路监控告警：
  • 监控SQS队列：跟踪队列长度、消息处理延迟、死信队列消息数，当队列堆积超过阈值时触发告警。
  • 监控DocumentDB：跟踪存储占用量，防止TTL机制失效导致存储溢出。
  • 监控服务状态：跟踪Payment API、Invoice API的调用成功率、响应耗时，及时发现遗留DB或下游服务异常。
• 幂等性保障：由于SQS存在消息重复分发的可能，Payment API和Invoice API需实现幂等处理。例如以支付订单ID作为幂等键，处理前先校验该订单是否已被处理，避免重复操作遗留DB或生成重复发票。
• 全链路日志追踪：为所有请求分配唯一的请求ID，从Integrator API发起请求开始，贯穿DocumentDB存储、SQS消息传递、Payment API处理、Invoice API调用全流程，便于快速关联日志排查问题。

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