Skip to main content

Serverless Architecture

Serverless takes Microservices Architecture's "independent, small units of deployment" idea and pushes it one step further: instead of deploying a service that runs continuously on infrastructure you provision and manage, you deploy a single function, and the cloud provider runs it only when triggered, for exactly as long as it takes to execute, then stops it entirely. There are still servers underneath — the name refers to not having to think about them, not their literal absence.

Pay for execution, not for idle time​

A traditional service — even a small microservice — runs continuously on a server that's provisioned, patched, and paid for whether or not it's actively handling a request at any given moment. A serverless function (FaaS — Function as a Service) is billed per invocation and per unit of compute time actually used, and scales from zero instances to many and back to zero automatically, with no capacity planning from the developer at all. This is the sharpest possible version of matching cost to actual load — Database Scaling and horizontal scaling generally are about adding capacity as load grows; serverless additionally scales all the way down to zero cost when there's no load at all.

System Design Lab

Triggers, not just HTTP requests​

A serverless function isn't limited to answering HTTP calls behind an API Gateway, though that's a common entry point. It can just as naturally be triggered by a message landing on a queue, an event published to a pub/sub topic, a file being uploaded to storage, or a CDC stream emitting a database change. This makes serverless functions a natural implementation vehicle for Event-Driven Architecture: a function that does one specific thing in reaction to one specific kind of event, with no need to keep a server running and waiting between events.

Cold starts: the cost of scaling to zero​

Scaling all the way down to zero has a real, direct latency cost: when a function hasn't run recently, the platform has to provision a fresh execution environment before running it — a cold start — adding real latency (often tens to hundreds of milliseconds, sometimes more depending on the runtime) to that particular invocation, compared to a "warm" one reusing an already-running environment. This is a genuinely different failure mode than anything in a traditional always-on service, and it's the first thing worth naming when a design proposes serverless for a latency-sensitive path.

What you give up: control and long-running work​

Two limits follow directly from serverless's execution model, and both are worth naming precisely:

  • Execution time limits. Providers cap how long a single invocation may run (commonly minutes, not hours), because the model assumes short, bursty units of work — a long-running batch job or a persistent WebSocket connection doesn't fit this shape at all and needs a traditional always-on service instead.
  • No control over the underlying machine. No choice of OS-level tuning, no local disk state that persists between invocations, no long-lived in-memory cache guaranteed to survive to the next call — every invocation has to assume it might be starting from scratch, which pushes any state that needs to persist out to an external store the function calls into (a database, a distributed cache).

Why this matters in an interview​

Serverless is the right answer for event-triggered, short-lived, bursty, or infrequent workloads — a thumbnail generator triggered by an upload, a nightly report, a lightly-used internal API — where paying for idle always-on capacity would be wasteful. It's the wrong answer for a latency-critical hot path that can't tolerate cold starts, or anything long-running or stateful. Naming that distinction, rather than treating serverless as a strictly "more modern" default, is what separates a considered answer from a trend-following one.

Serverless vs. always-on services: pros and cons​

Pros

  • Pay only for actual execution time — zero cost when there's no load at all
  • Scales automatically from zero to many instances with no capacity planning
  • Removes server provisioning and patching entirely from the developer's responsibility

Cons

  • Cold starts add real, sometimes significant latency to infrequent invocations
  • Hard execution time limits rule out long-running or persistent-connection workloads
  • No control over the underlying runtime, and no guaranteed local state between calls

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.