关于AWS API Gateway与EventBridge处理Stripe事件的架构疑问

EventBridge的核心作用（不止扇出） #

• 解耦职责：把签名验证（轻量、高可用要求）和业务逻辑处理（可能复杂、依赖多）拆分开，各自独立开发、部署和维护，避免修改验证逻辑影响业务，反之亦然。
• 可控的重试与容错：EventBridge自带可配置的重试策略（次数、间隔），业务逻辑Lambda失败时自动重试，还能配置死信队列存储处理失败的事件，避免事件丢失。如果是单Lambda架构，失败后Stripe会按自身规则重复发Webhook，容易导致重复处理，且重试逻辑不可控。
• 事件持久化与审计：EventBridge会留存事件日志，方便后续回溯、审计，或者需要重新处理历史事件时直接从EventBridge触发，不用依赖Stripe重新推送。
• 流量削峰：当Stripe突发大量事件时，EventBridge可以缓冲流量，避免直接压垮业务处理Lambda，保证系统稳定性。
• 灵活扩展多消费者：后续如果需要把事件同步到其他服务（比如CRM、数据仓库、日志系统），只需在EventBridge添加新规则即可，无需修改前端的验证Lambda或业务Lambda，扩展性极强。

单Lambda（验证+业务逻辑）架构的潜在问题 #

• 耦合度高：验证逻辑和业务逻辑混在同一代码中，代码臃肿，维护成本高，修改其中一部分时容易影响另一部分，不符合单一职责原则。
• 超时与重试风险：API Gateway的最大超时时间是29秒，如果业务逻辑处理耗时较长（比如调用外部服务、批量操作），容易触发超时，Stripe会重复发送Webhook，导致业务逻辑重复执行，需要额外实现复杂的幂等逻辑。
• 扩展性差：后续要新增事件消费者时，必须修改该Lambda的代码，引入更多依赖，增加出错概率。
• 容错能力弱：如果业务逻辑依赖的资源（比如数据库）临时不可用，Lambda执行失败后，没有内置的重试机制和死信队列，容易丢失事件或导致重复处理。

总结 #

如果你的业务规模小、事件量少、逻辑简单，单Lambda架构可以暂时满足需求，但从长期稳定性、可维护性和扩展性来看，引入EventBridge的分层架构更优。

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