What is serverless architecture?

The layers of a serverless system

A user or another system first reaches an interface such as an API, event bus, queue, schedule, or object store. Compute or workflow services process the request. Managed databases and storage hold state. Identity, encryption, telemetry, deployment, and cost controls cross every layer.

The architecture is easier to operate when each component has one visible responsibility and every connection has an owner. A diagram of services is not enough: capture the contracts, permissions, failure behavior, and operational signals between them.

Synchronous and event-driven paths

Synchronous calls are useful when the caller needs an immediate answer. Asynchronous events and messages are useful when work can be accepted, buffered, retried, or processed independently. Most production systems need both, with clear boundaries between the request path and background work.

Event-driven architecture can reduce coupling between producers and consumers, but it introduces eventual consistency and more complex tracing and recovery. Use events for meaningful state changes, define schemas and ownership, and decide how consumers handle duplicates, ordering, delay, and poison messages.

Decisions to make before choosing services

Start with the business operation: who initiates it, how quickly it must complete, which data changes, what failure means, and who owns recovery. Those answers determine whether the path should be synchronous, asynchronous, orchestrated, or split into stages.

Then make non-functional requirements explicit. Expected traffic shape, data sensitivity, regional needs, recovery objectives, service quotas, audit requirements, and team experience should shape the design before convenience or novelty does.

Common serverless architecture mistakes

A large function can hide several responsibilities behind one deployment unit. A chain of synchronous functions can add latency and failure surfaces without creating useful boundaries. An event bus can become an undocumented integration layer if schemas and consumers are not governed.

Other warning signs include broad IAM policies, retries without idempotency, queues without age or dead-letter alarms, dashboards that show service activity but not business outcomes, and infrastructure changes that cannot be reviewed from source. These are design problems, not limitations that a new service name will solve.