Why a Developer Chose a Long-Lived Node Process Over Serverless for Real-Time Apps

A developer building a live dashboard with thousands of persistent connections chose a long-lived Node.js process over a serverless architecture, arguing that serverless economics are fundamentally misaligned with real-time workloads. While serverless excels at short request-response tasks, its pricing model charges per invocation and connection-minute, making it costly for applications that maintain continuous open connections. Running an in-process state model eliminated repeated Redis round trips and turned fan-out to thousands of subscribers into a simple memory loop instead of thousands of billable calls. The trade-off required roughly a week of additional infrastructure work — covering graceful draining deploys, manual scaling decisions, and memory management — paid once upfront. The developer's broader takeaway is that engineers should identify the core constraint of their product before defaulting to the most popular architectural recommendation.