What Is Serverless Architecture?
Serverless is a cloud execution model where your code runs in stateless functions that scale automatically — you pay per execution, not per server-hour.
Serverless is a cloud execution model where your code runs as short-lived, stateless functions that the platform starts on demand and shuts down after each request. You write the function; the provider handles servers, scaling, and uptime, and you pay per execution rather than per server-hour.
The name is misleading: servers still exist. "Serverless" means you don't provision, patch, or scale them. A function sits idle at zero cost, spins up when something triggers it, runs, returns a result, and disappears.
How it works
The lifecycle is the same across providers:
- You write a function — a Next.js API route, a Supabase Edge Function, an AWS Lambda handler.
- A trigger fires it — an HTTP request, a database event, a cron schedule, a queue message.
- The platform runs an instance — allocating compute, executing your code, then tearing it down. Concurrent requests get separate instances, which is how serverless scales horizontally without you configuring anything.
- You're billed for what ran — typically by invocation count and execution duration (GB-seconds), not for idle time.
Because each invocation is stateless, you can't rely on in-memory data persisting between calls. State lives in a database, object storage, or a cache like Redis.
Common serverless platforms
| Platform | Runtime | Best fit |
|---|---|---|
| Vercel | Node.js + Edge | Next.js API routes, server components, edge middleware |
| Supabase Edge Functions | Deno | Logic that runs close to your Postgres database |
| AWS Lambda | Many languages | Foundational serverless, broad trigger and AWS-service support |
| Cloudflare Workers | V8 isolates | Ultra-low-latency code at the network edge |
Edge runtimes (Vercel Edge, Cloudflare Workers) run lighter V8 isolates geographically near the user, so they start almost instantly but restrict which Node.js APIs you can use. Standard runtimes (Lambda, Vercel's Node functions) give you the full runtime at the cost of slower starts.
When serverless fits — and when it doesn't
Serverless suits request/response workloads with uneven traffic: APIs, webhooks, form handlers, scheduled jobs, image processing, auth flows. For a SaaS MVP it's usually the right default — you ship a production API without renting or babysitting a server. A Next.js app on Vercel gives you serverless API routes, server components, and edge middleware out of the box, and the bill stays near zero until you have real traffic.
It's a poor fit when the work is long-running or stateful:
- Persistent connections — WebSocket chat or live collaboration servers expect a process that stays up, which contradicts the short-lived function model.
- Heavy or long background jobs — large video transcodes or multi-minute batch work hit execution time limits; use a dedicated worker or queue.
- Steady, high, predictable load — at constant high volume, a reserved server can cost less than per-invocation pricing.
In practice most apps are a mix: serverless functions for the API surface, plus a long-running server or worker for the few tasks that genuinely need one.
Cold starts: the main trade-off
When a function hasn't run recently, the platform has no warm instance ready, so the first request pays a startup penalty — loading the runtime and your code — before your logic runs. This is a cold start. Subsequent requests reuse the warm instance and are fast.
For most SaaS apps a cold start of a few hundred milliseconds is invisible. It matters for latency-sensitive paths, where the fixes are: keep functions warm (provisioned concurrency or scheduled pings), move to an edge runtime that starts near-instantly, or keep the function's dependencies small so it loads faster.
Common mistakes
- Storing state in the function — anything kept in a module variable can vanish on the next invocation. Persist it externally.
- Opening a fresh database connection per request — serverless can spawn many instances at once and exhaust a database's connection pool. Use a pooler (e.g. Supabase's pooled connection / PgBouncer) or a serverless-friendly driver.
- Treating it as free — idle is cheap, but heavy or runaway traffic on per-invocation pricing can cost more than a small server.
- Forcing long jobs into a function — work that exceeds the timeout belongs in a queue + worker, not a retried HTTP call.
Concrete example
A booking SaaS like BookBed runs its API as serverless functions: an HTTP request hits a POST /reservations route, a function validates the booking, writes to the database, and returns — then shuts down. A separate scheduled function handles recurring work like bidirectional iCal sync on a timer. No server runs in between, and cost tracks actual usage.
Key takeaways
- Serverless = you ship functions, the platform runs and scales the infrastructure, billed per execution.
- Default to it for SaaS APIs, webhooks, and scheduled jobs; reach for a long-running server only for persistent connections or heavy background work.
- Design for statelessness and pooled connections, and watch cold starts only where latency truly matters.
Want serverless wired into your stack the right way? Contact for a quote.