《奥德赛》70mm IMAX场次开票，15万张票几乎瞬间售罄。但计划总在变，退票时有发生，好座位会在凌晨三点突然冒出来。谁能第一时间发现这些“漏网之鱼”？

Temporal 的 Andrew Baker 做了个叫 IMAXXING 的服务：监控全美所有70mm IMAX场次，一旦有好座位放出，立刻通知订阅用户。这个周末项目上线后迅速走红，现在已有超过9000名用户在等票。

核心架构：一个用户一个工作流

Andrew 在视频里拆解了这套系统的架构，几个关键设计值得聊。

首先是实体工作流模式（Entity Workflow）。每个用户订阅对应一个常驻工作流，全国每个场次对应一个独立监控工作流。这种一对多的拆分，让系统能并行追踪数百个场次的余票变化，互不干扰。

其次是信号与智能去抖（Signals & Smart Debouncing）。场次工作流发现新座位后，通过信号（Signal）唤醒对应的订阅工作流。但这里有个问题：同一场次可能连续放出多个座位，如果每个座位都立刻推送，用户会被消息轰炸。

Andrew 的解法是在工作流内部加了一个60秒计时器：把这段时间内收到的所有提醒合并成一条摘要再推送。这个计时器在等待期间不消耗CPU，纯粹靠工作流状态机驱动——这正是 Temporal 的持久执行（Durable Execution）带来的好处。

无服务器扩缩容：按队列深度而非CPU

流量高峰时，监控频率和用户订阅数都会暴涨。Andrew 把 Temporal 的 worker 跑在 Google Cloud Run 上，作为无服务器容器运行。关键在于：扩缩容的指标不是通用的CPU使用率，而是任务队列深度——队列里积压的任务越多，自动扩容的实例就越多。

这种设计避免了过度预置资源，高峰过去后实例自动缩回，成本控制得很干净。

运维也用AI Agent加速

部署和监控面板的搭建，Andrew 用了现代编码Agent配合 Terraform 和 gcloud CLI 完成。基础设施即代码加上AI辅助，让这个项目的运维侧省了不少事。

持久执行改变了什么？

这套架构最反直觉的地方在于：你不需要自己维护定时任务（Cron Job）、重试数据库和告警队列。工作流状态本身就是队列和计时器——系统崩溃后，Temporal 能把历史回放到故障点，从那里继续执行，而不是从头再来。

这彻底改变了处理长生命周期状态和重试的思考方式。传统方案里，你要自己处理“任务挂了怎么办”“重试会不会重复推送”“状态存在哪里”这些问题。在 Temporal 里，这些是平台能力，不是业务代码。

几个值得借鉴的设计决策

  • 监控与通知解耦：场次工作流只负责发现座位变化，通过信号通知订阅工作流，两者互不阻塞
  • 去抖放在工作流内部：用计时器合并通知，而不是在应用层做复杂的限流逻辑
  • 无服务器跑worker：按任务队列深度扩缩容，比按CPU指标更贴合实际负载

如果你也在做类似的通知系统或监控服务，IMAXXING 这套架构提供了一个参考：把状态管理交给持久执行引擎，把扩缩容交给队列深度，把通知合并交给工作流计时器。剩下的，就是专注业务逻辑本身。

你有没有试过实体工作流模式，或者把工作流worker跑在无服务器环境上？遇到下游API抖动时，你又是怎么处理去抖的？