Inngest每月白送5万次调用，开发者连夜把队列拆了

5万次免费事件调用，零基础设施成本，一个npm包搞定后台任务队列——这不是某云厂商的促销套路，是Inngest直接把它做成了常态。

背景任务（Background Jobs）这东西，做过后台的都知道有多烦。Redis要搭，队列要管，重试逻辑要写，并发控制要调，半夜报警更是家常便饭。Inngest的玩法是：这些脏活我全包了，你只管写业务函数。

从"搭积木"到"写函数"

传统方案像乐高。买Redis、配BullMQ、写Worker、调监控，拼完才能跑。Inngest更像租车——npm install inngest，三行代码，直接上路。

核心就三个概念：Client（客户端）、Function（函数）、Event（事件）。Client负责跟Inngest云服务握手，Function是你写的业务逻辑，Event是触发信号。

代码层面，一个欢迎邮件流程长这样：用户注册触发事件→立即发邮件→等3天→发跟进邮件→再等7天→查活跃度→不活跃就发召回。全程用step.run()包业务逻辑，step.sleep()做等待，if分支随便写——Inngest会自动把状态持久化，函数中途崩溃也不怕，从断点续跑。

这背后是"持久化执行"（Durable Execution）的思路。不是让你自己存状态、写补偿逻辑，而是平台层保证：函数走到哪一步、中间数据是什么，全给你记下来。挂了重启，接着睡那7天，时间一到继续执行。

免费 tier 的边界在哪

每月5万事件，对早期项目够用了。按一个用户触发3-4个后台任务算，支撑一万多月活没问题。超了再升级，价格梯度跟Vercel、Supabase一个路数。

但免费不是阉割版。核心功能全开放：定时任务（Cron Jobs）、并发控制、限流（Throttling）、函数编排。甚至多步骤工作流——上面那个邮件 nurturing 流程，复杂度和成本无关，只跟你写的代码行数有关。

有个细节挺有意思。Inngest的函数运行在开发者自己的基础设施上，通过HTTP endpoint暴露给平台。数据不出境，敏感操作留在本地，平台只负责调度、重试、状态管理。这比纯SaaS方案多了层安全感，又比自托管方案少了运维负担。

部署也省事。Next.js里建个app/api/inngest/route.ts，serve()函数把本地函数注册成HTTP handler，Vercel/Netlify/Railway随便扔，自动扩缩容。

谁在偷偷用

官方没公布客户名单，但GitHub上的集成示例暴露了倾向：AI应用、电商SaaS、数据分析工具。这类产品的共同点是——后台任务多、流程长、状态复杂，但团队小、没专职DevOps。

一个典型场景：AI生成图片。用户提交提示词→排队等GPU→生成中→回调通知→失败重试→成功发邮件。用传统队列写，得处理状态机、超时、幂等、回调验证。用Inngest，一个函数里step.run()包生成调用，step.sleep()等回调，逻辑线性地摊在代码里，像写同步代码一样写异步流程。

另一个场景是定时任务替代。原本用node-cron或GitHub Actions跑脚本，现在写成Inngest函数，{cron: "0 9 * * *"}触发，自带重试、日志、监控。省了服务器，还多了可视化追踪。

坑和边界

不是所有场景都合适。超低延迟要求的任务（比如实时音视频处理），HTTP往返+平台调度有几十毫秒开销，得自己测。超大规模吞吐量（每秒上万事件），免费 tier 扛不住，得谈企业方案。

还有一个隐性成本：迁移。已有Redis/BullMQ/Sidekiq的存量系统，切过来要改调用方式、重构状态逻辑。Inngest提供了迁移指南，但代码债得自己还。

生态方面，相比AWS Step Functions或Temporal，Inngest的社区还在早期。复杂场景（Saga模式、人工审批节点）的现成方案少，得自己拼。

但反过来看，这也是机会。Step Functions按状态转换收费，账单难预测；Temporal要自托管集群，运维重。Inngest卡在一个中间地带：比Step Functions便宜透明，比Temporal轻量，比自研队列省心。

5万次免费调用，本质是降低试错成本。开发者可以先用它跑非核心流程（报表生成、邮件推送、数据同步），验证模式后再决定要不要深度依赖。这种"渐进式托管"的策略，和Vercel当年推前端托管一个打法。

最后留个数据点：Inngest的GitHub仓库 star 数在背景任务工具里排不进前三，但近半年增速超过BullMQ。开发者用钱包投票之前，先用脚投票了。

你的后台队列现在是什么状态？自研的、开源的、还是已经悄悄切到这类托管方案了？