今日已更新 262 条资讯 | 累计 42673 条内容
关于我们

Everyone Said 'Just Go Serverless.' I Ran a Long-Lived Node Process — Here's What That Bought

Yaseen Khatib 2026年09月13日 17:41 3 次阅读 来源:Dev.to

[ EXECUTIVE TEARDOWN // TL;DR ] A real-time product is defined by the connection that stays open, and the economics of serverless assume nothing stays open. In-process state turns per-message Redis round trips into memory reads, and fan-out into a loop rather than thousands of billable invocations. The honest cost: draining deploys, scaling decisions and memory discipline become mine — roughly a week of work paid once. The method transfers: find the constraint that governs the product, then check the default answer against it before accepting it. Everyone said “just put it on serverless.” For the product I was building — a live dashboard holding thousands of open connections, pushing telemetry as it happened — I ran a long-lived Node process instead. This post is about that decision, because the decision is the product. Know what your product actually is Serverless is close to unbeatable for request-response work: a function wakes, does one job, returns, and you pay for milliseconds. If that is your workload, the argument is over and you should stop reading. A real-time product is not that workload. Its defining feature is the connection that stays open — and the whole economic model of serverless is that nothing stays open. Every constraint that follows comes from that one sentence, and none of it is visible in a feature list. What a long-lived process buys you State that survives between messages: a subscription registry, an in-process cache, a rate-limit window. On serverless each of those becomes a Redis round trip, on every message, forever. Fan-out that is a loop, not a bill: pushing one update to 5,000 subscribers is an iteration over a Map. The same fan-out through a serverless gateway is 5,000 billable invocations. Backpressure you can actually apply: the socket tells you when the client is not keeping up. A stateless function has no idea a consumer is drowning, because it never sees the consumer twice. Warm everything: connection pools, compiled serialiser

本文内容来源于互联网,版权归原作者所有
查看原文