Serverless / FaaS Architecture

FaaS removes capacity management

Function-as-a-Service (AWS Lambda, Google Cloud Functions, Azure Functions) removes capacity management: you deploy a stateless function, the platform runs one isolated instance per concurrent request, scales that fleet from zero to thousands in seconds, and bills per invocation by GB-seconds of memory-time plus a per-request fee. There are no idle servers to pay for and no autoscaling group to tune. That is the whole pitch, and it is genuinely transformative for spiky, unpredictable, or glue-code workloads.

Cold starts

The catch is the execution model. Each function instance handles exactly one request at a time, so 500 concurrent requests means 500 warm instances. When no warm instance is free, the platform provisions a fresh one: download the package, start the runtime, initialize your code. That is a cold start, and it costs roughly 100ms for a lean Node or Python function up to 1s or more for a fat Java or .NET package, or a function that must attach an ENI to reach a VPC. Users on the p99 tail feel exactly those cold starts.

Mitigations, in order of leverage: provisioned concurrency (pay to keep N instances warm, which brings back a slice of the always-on cost you were trying to escape), smaller deployment packages and fewer heavy imports so init is faster, keeping the function out of a VPC or using VPC-native networking to skip ENI attachment, and lazy-loading SDK clients so you only initialize what a given request needs. Warm-ping hacks help marginally but do not scale to real concurrency.

The hard constraints

• Execution-time limit: Lambda caps at 15 minutes. Anything longer must be chunked or moved to a container or batch job.
• Statelessness: no local disk you can rely on across invocations and no in-process cache that survives. State goes to DynamoDB, S3, Redis (ElastiCache/MemoryDB), or a managed queue.
• Concurrency caps: accounts have a regional concurrency limit (often 1000 by default). A traffic spike can throttle you, and a downstream database with a 200-connection pool will melt long before Lambda does. Use reserved concurrency and a connection proxy (RDS Proxy) to protect stores.
• Cold-start-sensitive latency and vendor lock-in (triggers, IAM, and event shapes are provider-specific).

Multi-step logic does not belong inside one giant function. Orchestrate it with Step Functions or a durable-workflow engine: each step is its own function, retries and timeouts are declarative, and you get a visual execution history instead of a 900-second monolith.

Interview nuance: the cost model inverts at high steady load. FaaS is priced for bursty utilization; if a function runs flat-out 24/7, per-invocation billing costs several times what an equivalently sized, well-utilized container or reserved instance would. The crossover is roughly when sustained utilization passes ~40 to 60 percent. Saying "serverless is cheaper" without "for spiky load" is the tell of someone who has not seen the bill.

UPLOAD --> S3 event --> Lambda (per-file, stateless, auto-scale)
                              |  cold start 100ms-1s+
                              |  15-min cap, concurrency cap
                       write result --> S3 / DynamoDB
   multi-step? --> Step Functions orchestrates N small functions

Recap: FaaS trades capacity management for per-invocation billing and instant scale, which wins for spiky event-driven glue but loses on cold-start latency, hard execution limits, statelessness, and a cost model that inverts against containers under high steady load.