Serverless means you deploy a function rather than a server, and the platform runs it on demand and bills you for execution rather than for uptime - which is excellent for spiky, short, independent work and quietly terrible for several things people routinely use it for.
The pattern catalogues in this space are mostly written by platform vendors and describe what is possible rather than what ages well. After a decade of production use the picture is clearer, and it is more selective than the early enthusiasm suggested.
Table of contents
- The two properties that decide everything
- Patterns that hold up
- Patterns people regret
- Cold starts, in proportion
- The hybrid most systems settle into
- How this fits the rest of the stack
- FAQ
The two properties that decide everything
Every serverless trade-off comes from two facts about the execution model.
Instances are ephemeral and interchangeable. A function starts, handles work, and may vanish. It cannot hold state between invocations, cannot rely on local disk, and cannot be addressed individually. Anything durable goes to a database or object storage.
Billing is per execution-time, not per uptime. Idle costs nothing, which is transformative for spiky and low-volume workloads. Sustained load costs more than an equivalently-sized always-on process, because you are paying a premium for elasticity you are no longer using.
Read those two properties and you can predict, without any further information, which of your workloads will fit.
Patterns that hold up
- Event handlers. A file lands in storage, a message arrives, a row changes - do a discrete piece of work in response. This is the pattern serverless was designed for and it remains the best fit by a distance.
- Scheduled jobs. Nightly reports, cleanups, reconciliation. Idle most of the day, brief when it runs, and no server to keep alive for it.
- Webhook receivers. Traffic is unpredictable and bursty by nature, the work per call is small, and scaling to zero between bursts is exactly right.
- Queue workers with idempotent handlers. A queue decouples the producer from the consumer, absorbs bursts, and gives you retries for free. This is the single most useful pattern in the catalogue and the one that makes the rest reliable.
- Glue between managed services. Small transformations between systems that would otherwise need a service just to exist.
The common thread: short, independent, bursty, and stateless. Where all four hold, serverless is genuinely excellent and hard to beat on cost.
Patterns people regret
Long-running work inside a request. Function timeouts are finite and often shorter than the job. Anything taking more than a few seconds belongs behind a queue, with the request returning a task reference immediately. This is the number one cause of production failures in AI features and file-processing pipelines alike.
Sustained high traffic. At steady load the per-execution premium adds up and a long-running process becomes both cheaper and faster. Teams often discover this well after the architecture is set, which is an unpleasant place to discover it.
Chatty function-to-function call chains. Each hop adds latency, a failure mode, and a cold-start risk. A call chain five functions deep is a distributed system with none of the tooling of one. If two functions always call each other, they are one function.
Anything holding a connection open. WebSockets, server-sent events, long polling, streaming responses. Possible on some platforms, awkward on all of them, and usually a sign the workload wants a long-lived process.
Databases with connection pools. Traditional relational databases have connection limits, and a function scaling to hundreds of concurrent instances will exhaust them. This needs a connection proxy or a pooler, and it is a real operational concern rather than a footnote.
Cold starts, in proportion
A cold start is the delay when a function has to be initialised before handling a request. It is the most discussed serverless problem and rarely the most important one.
It matters for user-facing synchronous requests where a delay is visible, and for anything with a strict latency budget. It matters much less for event handlers, queue workers, and scheduled jobs, where a few hundred milliseconds is noise.
The mitigations are ordinary: keep the deployment package small, avoid heavy initialisation at module load, choose a runtime with fast startup, and use provisioned concurrency where the platform offers it and the latency genuinely matters. Note that provisioned concurrency means paying for idle capacity, which is paying to undo the main benefit - a reasonable trade sometimes, and worth naming as the trade it is.
The hybrid most systems settle into
Very few mature systems are entirely serverless or entirely not, and the split that emerges is fairly consistent.
A long-running service handles the main application: predictable traffic, connection pooling to the database, streaming where needed, no cold starts on the critical path. Functions handle the edges: event handlers, scheduled jobs, webhook receivers, and queue workers where the load is spiky and the work is discrete.
That split plays to both models’ strengths and avoids both failure modes. It also has the practical advantage that the long-running service is an ordinary container, which means the decision is reversible - you can move work between the two halves as you learn where it actually belongs, without rewriting anything.
How this fits the rest of the stack
The hybrid needs a long-running service somewhere, and pricing that half is what makes the split a decision rather than a default. The RunxBuild hosting calculator shows the service, the database, the storage, and the bandwidth as separate line items so the always-on portion has a concrete number. RunxBuild runs Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker services with autoscaling between a floor and ceiling plan you set, plus managed MySQL and Postgres with connection limits and private networking.
Useful related references:
- Astro Islands Architecture: Ship HTML, Hydrate Only What Moves
- Serverless Kubernetes: When It Works, When It Doesn’t, When to Pick It
- Handling POST Requests in Vercel Serverless Functions
- Services on RunxBuild
FAQ
What is serverless architecture?
An execution model where you deploy functions rather than servers, the platform runs them on demand, and you are billed for execution time rather than uptime. Instances are ephemeral and interchangeable, so nothing durable can live in them, and idle costs nothing.
When is serverless a bad choice?
For sustained high traffic, where per-execution pricing exceeds an always-on process. For long-running work inside a request, since timeouts are finite. For anything holding a connection open, like WebSockets or streaming. And for deep function-to-function call chains, which are distributed systems without the tooling.
How bad are cold starts really?
They matter for user-facing synchronous requests with a latency budget and are close to irrelevant for event handlers, queue workers, and scheduled jobs. Keep packages small and initialisation light; provisioned concurrency fixes it at the cost of paying for idle capacity, which undoes the main benefit.
How do serverless functions work with a relational database?
Awkwardly without help. Traditional databases have connection limits, and functions scaling to hundreds of concurrent instances will exhaust them. You need a connection pooler or proxy between the two, and it should be planned for rather than discovered under load.
Should I build everything serverless?
Most mature systems end up hybrid: a long-running service for the main application where traffic is predictable and connections are pooled, with functions for event handlers, scheduled jobs, webhooks, and queue workers where load is spiky and work is discrete.