Serverless Stateless Execution and Cold Starts

Definition

This is the concept for understanding the model (AWS Lambda, etc.) where, instead of putting your code on an "always-on server," the cloud briefly spins up an execution environment only when a request arrives, runs it, and shuts it down when done. In exchange for handing server management to the cloud, constraints your code must respect arise (it can't remember state; the first run is slow).

Let's unpack the terms first: stateless means the function can't use in the next call the memory (values stored in memory) of a previous call; ephemeral means the execution environment lives briefly and then disappears; and cold start is the phenomenon where the first request is slow because a new execution environment is being spun up for the first time and the code is being initialized.

To sum up, a serverless function is a stateless process that runs in an isolated execution environment that is ephemeral per request. The latency of the first call—booting a new instance and initializing the runtime (the environment needed to run the code)—is the cold start. This contrasts with a resident server that is always up in memory (a long-running process—a traditional server that stays on and maintains state).

Why It's Needed

A resident server can keep an index, connection pool, or cache continuously in memory, but a serverless platform, for cost and scalability, "creates instances when needed and reclaims them when idle." Therefore, if you put "things that must stay up in memory" (a search engine, an in-memory DB, the write handle of a file-based DB, etc.) inside the function, it won't work as expected. Understanding this model lets you correctly divide "what can go inside the function and what must go outside."

How It Works

1. When a request comes in, the platform reuses a warm instance if one exists, and boots a new instance otherwise (cold start).
2. Module-level code runs only once while the instance is alive → initialize heavy immutable objects here as a lazy singleton to aim for warm reuse.
3. The temporary filesystem is readable during execution, but disappears when the instance dies. Send persistent writes to external storage.
4. The files included in the function are statically determined at build time (file tracing), so build artifacts read dynamically at runtime must be explicitly included.

Practical Application

// Module-level lazy singleton: pay the cold-start cost only once, warm reuse
let indexSingleton: SearchIndex | null = null;

function getIndex(): SearchIndex {
  if (indexSingleton) return indexSingleton; // warm reuse
  const raw = readFileSync(indexFilePath, "utf8"); // build artifact
  indexSingleton = SearchIndex.load(raw);
  return indexSingleton;
}

For build artifacts read at runtime (e.g., a pre-built index file), specify the path in the bundle tracing config so it isn't dropped on a cold start. Flow request-specific data through arguments / request context, not through module globals.

Tradeoffs

A resident server maintains memory state freely but has high operational / scaling cost. Serverless is advantageous for scale / cost but is subject to cold-start latency and the stateless constraint. Putting a library-style index inside the function deploys lightly without external hosting, but large-scale / advanced tokenizing needs a separate resident engine.

When Not to Use It

A search-engine / DB process that must stay up at all times, mutable state that needs to be shared across instances, and large persistent-write workloads should not be placed inside the function. Split such dependencies out into managed services / dedicated servers.

Common Mistakes

• Storing request-specific data in module global variables → concurrency contamination / data loss (when instances are shared).
• Not putting build artifacts read at runtime into the bundle tracing, so files are missing on a cold start.
• Writing persistent data to the temporary filesystem and expecting it to survive.

Related Concepts

• inverted-index-full-text-search — the data-structure background when choosing an in-function library-style index over a resident engine.
• single-source-of-truth-content-metadata — adjoins the choice to avoid a runtime DB and decide via build artifacts.