05.03 · Concept
Long-Running Servers
Describe what a persistent process gives you that a function does not: warm state, connections and background work.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Persistent server processes keep useful state alive between requests: warm caches, reusable network clients, connection pools and background workers. That reduces repeated setup work and enables ongoing tasks, but the state is only local to that process and disappears on restart, reschedule or routing to another replica.
What this lesson answers
- what do long-running servers provide over functions
- when is in-memory server state safe to use
- how do persistent database connections help deployments
Notes
Long-Running Servers — Long-running servers exist to keep a persistent process alive across many requests, so warm in-memory state, open network connections, and background workers survive instead of being rebuilt or killed on every function invocation.
Key Concepts: - A long-running server process can handle requests over one lifetime, while a typical function invocation handles one event and then may be frozen or destroyed after execution. - Warm in-memory state can persist across requests, such as a Node.js `Map` cache holding 10,000 recently used user records until the process…
References
Common questions
- Why use a long-running server instead of a function?
- A long-running server keeps a process alive across many requests. That means cached objects, database clients, connection pools and worker loops can survive beyond a single request. A function is usually built around one event at a time, so anything warm may be frozen, discarded or rebuilt later.
- Can I rely on memory inside a server process?
- Use process memory as a cache or optimisation, not as durable storage. It can vanish when the process restarts, a container is replaced or traffic lands on another replica. Anything that must be correct across failures or instances belongs in shared storage such as a database or external cache.
- What can go wrong with background work in a server?
- Background work is useful for polling, refreshing credentials and maintenance tasks, but it must be bounded and owned deliberately. Starting a new loop from each request can multiply work until it overloads dependencies. In-process jobs also disappear if the server is killed before they finish.
Short definition: what is Long-Running Servers?