基于AWS的可定制多渠道外呼营销系统设计及线索延迟方案问询

核心需求回顾 #

• 支持多渠道营销活动，运行中可动态增删渠道、编辑步骤间延迟
• 线索上传后按自定义延迟规则触发渠道流程，支持流程中途修改
• 单用户单日单渠道执行有阈值，超量自动滚动至次日
• 活动限定执行时间窗口（如10:00-18:00）

原思路的痛点分析 #

1. 思路一（Step Functions + SQS）：SQS延迟队列最大仅支持15分钟延迟，无法满足长周期流程；单线索绑定一个Step Function实例成本过高；滚动至次日的逻辑难以通过SQS原生能力实现。
2. 思路二（DynamoDB定时扫描）：批量修改活动流程需更新大量线索记录，成本高且效率低；DynamoDB无合适GSI时，按时间筛选可执行记录性能差，定时扫描易引发资源瓶颈。

最优架构方案：EventBridge Scheduler + Step Functions + DynamoDB + SQS #

结合各AWS服务的优势，构建灵活、可扩展的延迟处理体系：

1. 数据层设计（DynamoDB） #

创建3张核心表，覆盖配置、线索、阈值管理：

• Campaigns表：主键campaignId，存储活动配置：channels（渠道步骤列表，含每步延迟）、timeWindow（执行时间窗口）、status（活动状态）
• Leads表：主键leadId，存储线索生命周期数据：campaignId、userId、currentStep（当前执行到的渠道）、nextExecutionTime（下一次执行的绝对时间）、executionHistory（各渠道执行记录）
• DailyThresholds表：复合主键userId#channelId（分区键）+date（排序键），存储单日执行计数与阈值：count（当日已执行次数）、threshold（阈值上限）

2. 延迟触发与流程编排 #

• 线索初始化：线索上传后写入Leads表，根据活动初始步骤的延迟规则，计算首次执行时间（若不在时间窗口内，自动调整至下一个窗口起始点），通过EventBridge Scheduler创建定时任务，触发Step Functions工作流。
• Step Functions工作流逻辑：
  1. 时间窗口校验：检查当前时间是否在活动窗口内，若不在则更新Leads表的nextExecutionTime为次日窗口起始点，创建新的定时任务后结束当前流程。
  2. 阈值校验：查询DailyThresholds表，若当日执行次数已达阈值，更新nextExecutionTime为次日窗口起始点，创建新定时任务后结束流程。
  3. 执行渠道任务：调用外呼服务执行任务，更新DailyThresholds的计数；根据活动下一个渠道步骤的延迟规则，计算下一次执行时间，更新Leads表并创建新的定时任务。
  4. 流程收尾：若已完成所有渠道步骤，标记线索流程为完成。

3. 活动动态编辑的实现 #

• 当用户修改活动配置（增删渠道、调整延迟）：
  1. 直接更新Campaigns表的对应字段。
  2. 通过DynamoDB Streams触发Lambda，扫描该活动下所有未完成的线索：
     • 根据新的活动流程，重新计算线索的nextExecutionTime
     • 调用EventBridge Scheduler API删除旧的定时任务，创建新的定时任务

4. 关键服务的优势利用 #

• EventBridge Scheduler：支持最长1年的延迟触发，完美覆盖长周期流程；可通过API动态创建/删除定时任务，适配活动流程的中途修改。
• DynamoDB Streams：实时监听活动配置的变更，自动触发线索执行计划的批量更新，避免手动扫描全表的低效操作。
• Step Functions：标准化流程编排，支持分支、重试逻辑，可处理外呼失败的重试场景；按执行次数计费，比单线索绑定长期实例成本更低。
• SQS：可选作为外呼任务的缓冲层，控制并发执行量，避免瞬时请求过高导致的服务压力。

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