Module 11 · Architectural patterns · Lesson 4 of 9
Serverless
Functions that run on demand with no servers to manage, billed per invocation. The execution model and cold starts, where it shines (event handlers, bursty and spiky work, glue), where it hurts (long-lived connections.
Why it matters
Serverless promises that you write a function and the platform handles everything else: provisioning, scaling from zero to thousands of instances, patching and billing by the millisecond. For event handlers, spiky workloads and glue between managed services it delivers on that promise at remarkable cost efficiency. For a latency-sensitive API under steady heavy load it can be slower and more expensive than servers you run. Knowing which is which is the design skill, and interviewers probe it because the marketing is louder than the trade-offs.
The idea
In Functions as a Service, you deploy small units of code that the platform invokes in response to events: an HTTP request, a message on a queue, a file landing in object storage, a schedule. The platform creates execution environments as needed, runs the function, keeps the environment warm for a while for reuse, and tears it down when idle. You pay for invocations and execution time, nothing when idle. State lives entirely in external managed services.
Cold starts and the execution model
A cold start happens when no warm environment exists: the platform must allocate one, load the runtime and your code, and run initialisation, which costs from tens of milliseconds (small Node or Go functions) to seconds (large JVM functions with heavy dependencies). Warm invocations reuse the environment and skip that cost. Mitigations: small deployment packages, lazy initialisation, lighter runtimes, provisioned concurrency (pre-warmed instances you pay for), and keeping latency-critical paths off functions entirely. Each environment handles one request at a time in most platforms, so concurrency equals instance count, and platforms cap it per account and per function.
Where it shines
- 1
Event handlers
Resize an image when it is uploaded, process a message from a queue, react to a database change. The event source is the trigger and scaling is automatic. - 2
Spiky or bursty traffic
A ticket drop, a nightly batch, a webhook receiver that is idle most of the day: pay nothing when idle and scale to thousands when needed. - 3
Glue and automation
Scheduled jobs, infrastructure automation, lightweight APIs for internal tools, chatbot backends. - 4
Edge logic
Edge functions run close to users for personalisation, redirects, authentication checks and A/B assignment on the request path.
Where it hurts
| Problem | Why | Alternative |
|---|---|---|
| Latency-sensitive paths | Cold starts add tail latency; per-request environments add overhead | Provisioned concurrency, or long-running services for the hot path |
| High steady load | Per-invocation pricing exceeds the cost of a few always-on containers | Containers or VMs for the baseline, functions for bursts |
| Long-lived connections | WebSockets and streaming need a process that persists | A managed WebSocket gateway, or a service |
| Database connections | Thousands of concurrent functions each open a connection: a connection storm | External pooler or a data API; see Connection pooling |
| Long tasks | Execution time limits (minutes) | Step functions or workflow engines that chain functions; containers for long jobs |
| Local state and caches | No shared memory across instances; warm-instance caches are a hint, not a guarantee | External cache |
| Debugging and testing | Distributed by default; local emulation is partial | Strong observability from day one; structured logs and tracing |
The managed-service ecosystem
Serverless is less about functions than about assembling managed services: object storage, managed databases, queues, event buses, API gateways, authentication, workflow orchestration. The function is the glue. This brings operational relief and vendor coupling: the architecture is expressed in a provider's primitives and moving providers means re-expressing it. Infrastructure as code and keeping business logic in provider-independent modules reduce, but do not remove, that coupling.
Cost reasoning
Functions are cheap when idle and expensive when busy: a function running continuously costs several times an equivalent container. The break-even depends on utilisation; a workload busy more than roughly a third of the time usually favours containers. Mixed architectures are normal: containers for the steady API, functions for event processing and bursts.