Building with Feature Flags 3

Serverless functions make feature flags interesting because the application process may appear, handle traffic for a while, disappear, and later be replaced by many new execution environments.

Cold and warm invocations behave differently

cold invocation
   ↓
start runtime
   ↓
initialize feature client
   ↓
obtain configuration
   ↓
evaluate
   ↓
handle request

A warm invocation can often reuse the initialized client and cached configuration.

warm invocation
   ↓
reuse client
   ↓
local evaluation
   ↓
handle request

This applies to AWS Lambda, Azure Functions, Google Cloud Functions and similar execution models.

Keep the client outside the handler when the platform allows reuse

In Node.js or Python serverless functions, SDK initialization is commonly placed at module scope so warm invocations can reuse it. Creating a new client inside every handler invocation can increase latency, network activity and cost.

Be careful with initialization waits

Some SDKs need an initial configuration before they can make a targeted decision. Waiting indefinitely during a cold start is a bad failure mode.

Use bounded initialization, sensible defaults, and provider specific caching or bootstrap mechanisms where available.

Polling changes the economics

In a long running server, one process can poll periodically. In serverless, horizontal scaling may create many independent execution environments. If each environment polls a remote configuration service, request volume can grow quickly.

This is one reason pricing models must be tested against deployment topology rather than against the number of flag evaluations alone.

Local evaluation is especially valuable

A function should ideally evaluate a cached configuration in memory rather than make a remote decision call for every invocation. That protects latency and reduces dependence on the control plane.

Propagation speed is not the same as evaluation speed

Local evaluation can be extremely fast, but a newly changed flag still has to reach each execution environment.

control plane change
       ↓
configuration distribution
       ↓
function environment receives update
       ↓
next local evaluation uses new value

An emergency kill switch may therefore require a faster refresh strategy than a normal product experiment.

Serverless failure questions

  • What value is used during a cold start if configuration cannot be fetched?
  • Can warm environments continue with cached configuration?
  • How quickly does a production kill switch propagate?
  • Does the SDK open background connections that fit the execution model?
  • Does the feature platform charge by configuration request, evaluation, user, seat, or another unit?
  • How does concurrency affect that cost?

Use the cloud service as an example, not as the architecture

AWS Lambda may be the implementation today and Azure Functions tomorrow. The durable pattern is the same: initialize carefully, reuse when possible, evaluate locally, bound remote dependencies, and understand how ephemeral scale affects propagation and cost.

Feature Flags series

← Feature Flags in Backend Services   Feature Flags in Mobile Applications →