Orchestration, Limits & Trade-offs

Multi-Step Workflows

Individual functions are meant to be small and single-purpose — a genuinely multi-step business process needs an explicit coordination layer. AWS Step Functions (and similar tools) sequence, branch, retry, and handle errors across several functions declaratively, rather than one function manually invoking the next.

Concurrency Limits

A traffic spike can scale a function up so aggressively it overwhelms a downstream resource's own connection limit (a database, a third-party API) — something a fixed-size server pool would naturally throttle. Reserved/max concurrency settings on the function, or a queue in front of the downstream resource, are the standard mitigations.

Cost & Traffic Shape

Pay-per-invocation billing is attractive for spiky or low/unpredictable traffic — you pay nothing at zero traffic ("scale to zero"). But at high, sustained, predictable load, a reserved/always-on server can become cheaper per unit of work, since the pay-per-use premium that helps at low utilization works against you once utilization is consistently high. Choosing serverless is a cost-modeling decision based on expected traffic shape, not a universal default.

Edge Functions

Cloudflare Workers and similar edge platforms run at many geographically-distributed points close to users, using a lightweight isolate-based runtime rather than a full container/VM — drastically cutting cold-start latency, at the cost of a more constrained execution environment and shorter limits than a regional FaaS platform like AWS Lambda.

Observability & Local Testing

A single logical request often flows through several short-lived functions and managed services, making it harder to trace the full path than with one long-running process — distributed tracing (AWS X-Ray, OpenTelemetry) exists specifically for this. Local development is similarly harder: tools like LocalStack approximate managed cloud services locally, but rarely with full fidelity to the real environment.