diagrams
Backend

Serverless Request Flow

A serverless request flow describes how an HTTP request triggers the lifecycle of a Function-as-a-Service (FaaS) — from cold-start initialization through execution and response — on platforms like AWS Lambda, Google Cloud Functions, or Azure Functions.

diagram.mmd — sequence
Edit in Graphlet →
Serverless Request Flow sequence diagram
About Source

A serverless request flow describes how an HTTP request triggers the lifecycle of a Function-as-a-Service (FaaS) — from cold-start initialization through execution and response — on platforms like AWS Lambda, Google Cloud Functions, or Azure Functions.

What the diagram shows

This sequence diagram involves four participants: Client, API Gateway / Trigger, FaaS Platform, and Function Code.

Two paths are shown:

Cold start path (no warm instance available): 1. The client sends a request that hits the API gateway (e.g., AWS API Gateway or an HTTP trigger). 2. The platform has no warm instance ready — it must provision a new execution environment. 3. The runtime is initialized: container image pulled, runtime process started, initialization code (init phase) executed. 4. The handler function is invoked with the event payload. 5. The function executes, calls downstream services or databases, and returns a response. 6. The execution environment is kept warm briefly to serve subsequent requests.

Warm start path (instance already warm): 1. A subsequent request arrives while the environment is still alive. 2. The handler is invoked directly — skipping all initialization steps. 3. Response time is dramatically lower.

Why this matters

Cold starts are the primary operational challenge of serverless architectures. A Java or .NET function with heavy dependency loading can add hundreds of milliseconds to the first request after idle periods. Strategies to mitigate cold starts include provisioned concurrency (pre-warming instances), minimizing dependency footprint, and using runtimes with faster startup times (Go, Rust, Node.js).

For edge deployments with even lower latency requirements, see Edge Function Execution. For long-running async workloads that don't fit the serverless request-response model, see Background Job Processing.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

A serverless request flow describes how an HTTP request triggers the lifecycle of a Function-as-a-Service (FaaS) — from cold-start initialization through execution and response — on platforms like AWS Lambda, Google Cloud Functions, or Azure Functions. The key characteristic is that the cloud provider manages all infrastructure; developers deploy code only.
When no warm instance is available, the FaaS platform must provision a new execution environment: pulling the container image, starting the runtime process, and running the function's initialization code. Only after this setup is complete does the handler receive the event payload. Cold starts can add anywhere from 50ms (Node.js, Go) to several hundred milliseconds (Java, .NET with heavy dependencies) to the first request after an idle period.
Serverless is well-suited for event-driven workloads with variable or unpredictable traffic — file processing triggers, webhook handlers, scheduled jobs, and API backends with spiky usage. It eliminates server management overhead and scales to zero during idle periods, making it cost-effective for intermittent workloads. Avoid serverless for long-running processes, workloads requiring persistent connections (like long polling), or latency-sensitive paths where cold starts are unacceptable.
Serverless functions run at a fixed cloud region using container-based execution environments, with cold starts that can add hundreds of milliseconds but with rich runtime capabilities including database connections and full Node.js APIs. Edge functions run globally at CDN PoPs using V8 isolates with sub-millisecond cold starts, but with a constrained runtime — no persistent connections, limited execution time, and no access to most Node.js APIs. Choose serverless for complex stateful logic; choose edge for ultra-low-latency stateless operations close to the user.
mermaid
sequenceDiagram participant C as Client participant GW as API Gateway / Trigger participant FP as FaaS Platform participant FN as Function Code C->>GW: HTTP request GW->>FP: Invoke function with event payload alt Cold start - no warm instance FP->>FP: Provision execution environment FP->>FP: Pull runtime container image FP->>FP: Start runtime process FP->>FN: Run initialization code FN-->>FP: Init complete FP->>FN: Invoke handler with event FN->>FN: Execute business logic FN->>FN: Call downstream services or DB FN-->>FP: Return response payload FP-->>GW: Function response GW-->>C: HTTP response FP->>FP: Keep environment warm for reuse else Warm start - instance available FP->>FN: Invoke handler with event FN->>FN: Execute business logic FN-->>FP: Return response payload FP-->>GW: Function response GW-->>C: HTTP response end
Copied to clipboard