Serverless architecture

In a serverless architecture, the team writes small functions and wires together fully managed cloud services (storage, queues, databases, authentication). The cloud provider runs the code only when an event triggers it, scales it automatically, and bills for actual use rather than for idle servers.

There are still servers, of course; the point is that the team never provisions, patches or scales them.

Diagram

flowchart LR
    user[Client] --> gw[Managed API gateway]
    gw --> fn1[Function: create order]
    fn1 --> db[(Managed database)]
    fn1 --> q[[Managed queue]]
    q --> fn2[Function: send receipt]
    upload[File upload] --> store[(Object storage)]
    store -- object created event --> fn3[Function: resize image]

How it works

• Functions as a service (FaaS). Small units of code run in response to events: an HTTP request, a queue message, a file upload or a schedule.
• Managed backing services. State lives in managed databases, object storage and queues, never in the function itself.
• Automatic scaling. The platform runs as many copies as needed, including scaling to zero when there’s no traffic.
• Pay per use. Cost follows invocations and execution time instead of reserved capacity.

Pros

• No infrastructure to run: no servers, operating systems or capacity planning.
• Scales automatically: from zero to large bursts without configuration.
• Low cost for spiky or low traffic: idle time costs nothing.
• Fast to build: managed services cover authentication, storage and messaging out of the box.

Cons

• Cold starts: a function that hasn’t run recently can take noticeably longer to respond.
• Limits: execution time, memory and payload size are capped by the platform.
• Vendor lock-in: triggers, permissions and managed services are provider-specific.
• Cost at sustained high load: constant heavy traffic can cost more than containers or reserved instances.
• Harder local testing and debugging: behavior depends on cloud services that are hard to reproduce on a laptop.

When to use it

• Event-driven workloads: file processing, webhooks, scheduled jobs, stream processing.
• Applications with unpredictable or spiky traffic.
• Small teams that want to ship without an operations function.
• Glue code between managed services.

When to avoid it

• Long-running or compute-heavy processing that exceeds platform limits.
• Latency-critical paths where cold starts are unacceptable.
• Steady, high-volume workloads where reserved compute is cheaper.
• Organizations that must stay portable across cloud providers.

Common pitfalls

• Function sprawl. Hundreds of tiny functions with no ownership or structure. Group functions by service.
• Chaining functions synchronously. One function calling another and waiting multiplies latency and cost; use queues or workflows.
• Unbounded concurrency. Auto-scaling can overwhelm a downstream database. Set concurrency limits.
• Non-idempotent handlers. Event sources retry, so handlers must tolerate duplicates. See idempotency.

Related patterns

• Event-driven architecture
• Microservices
• Backend for frontend
• Workflow orchestration (step functions)

Glossary: idempotency

Further reading

• Mike Roberts, “Serverless Architectures” (martinfowler.com)
• Your cloud provider’s serverless best-practices guide