Serverless
system design,
from first principles.

Every system does some mix of five jobs: it accepts requests, runs logic, stores state, moves messages, and keeps records. Traditionally you did all five on machines you owned — which meant patching, scaling, capacity planning, and 2 a.m. pages. Serverless design means picking a managed AWS service for each job, so the undifferentiated work belongs to AWS and your effort goes into the part that's actually yours: how the pieces fit together.

That's why system design matters more, not less, in a serverless world. The services are commodities; the architecture is the product. Three properties are worth internalizing early:

Pay-per-use. Lambda bills per invocation, DynamoDB per request, S3 per gigabyte. An idle system costs approximately nothing — ideal for internal tools with bursty, unpredictable traffic. Scale-to-zero and scale-to-lots. The same design serves ten requests a day or ten thousand a minute without re-architecture. Everything is an API call. Every action against every service is an authenticated, loggable API call — which is precisely what makes serverless systems so amenable to audit and access control, a theme we'll return to in chapter 07.

The simplest serverless system, and the one you're using right now: HTML, CSS, and JavaScript sit in an S3 bucket, CloudFront caches them at edge locations around the world, and a CI/CD pipeline redeploys the whole site on every push to main. There is no server, no runtime, no database — and therefore almost nothing to attack, patch, or pay for.

Don't let the simplicity fool you into thinking it's only for brochures. Internal documentation portals, dashboards that read from an API (pattern 02), report viewers, training material — a surprising share of internal tooling is "a static front-end plus a small API."

This is the pattern to know cold, because it's the serverless answer to the classic three-tier web app: a front door, business logic, and a database. A client calls API Gateway, which authenticates the request and hands it to a Lambda function, which reads or writes DynamoDB and returns a response — all synchronous, all within a couple hundred milliseconds, all fully managed.

Nearly every internal tool starts here: a CRUD API over a well-modeled table. The discipline that pays off is designing the DynamoDB table around your access patterns — the exact queries you'll ask — rather than around entities the way you would in SQL. Write those queries down first; the table design follows.

The single most important idea in distributed systems is decoupling: letting the part that accepts work run at a different speed — and fail at different times — than the part that does the work. A queue is how. The producer drops a message in SQS and immediately responds to the user; a worker Lambda picks messages up at its own pace and processes them.

This buys you three things at once. Burst absorption: a spike of 10,000 requests becomes a backlog that drains smoothly instead of a wall of timeouts. Failure isolation: if the worker (or a downstream dependency) is broken, messages wait safely in the queue instead of being lost. Retries for free: a message that fails processing reappears on the queue and is tried again — and after too many failures, moves to a dead-letter queue (DLQ) for a human to inspect.

A queue connects one producer to one consumer. But mature systems have facts that many parts care about: a document was submitted, an assessment was approved, a policy changed. An event bus inverts the relationship — the producer publishes the fact once, to EventBridge, without knowing or caring who's listening. Rules on the bus match events by pattern and route copies to every interested target.

The architectural payoff is extensibility. When a new requirement arrives — “we also need to notify the review team,” “we also need to update the search index” — you add a rule and a subscriber. The producing code doesn't change, isn't redeployed, and can't be broken by the addition. Compare that to a Lambda that calls four downstream services in a row: every new consumer is a code change, and any consumer's failure is the producer's problem.

Some processes are too important to leave implicit. An intake review, an access request, an approval chain — these have states, branches, deadlines, and often a human in the loop. You could wire them together with queues and events, but the logic ends up smeared across a dozen functions where nobody can see it. Step Functions makes the workflow itself a first-class, visible artifact: a state machine you can read as a diagram, where every execution records exactly which path it took, with what data, and why.

That last property is quietly the killer feature for governance-heavy work: the execution history of a state machine is documentation that the defined process was followed — every time, with timestamps. One honest caveat: Step Functions only keeps that history for about 90 days after an execution completes (and Express workflows only record history via CloudWatch Logs at all). So treat it as the working record, not the archive — the durable proof lives wherever you export it, which is exactly what pattern 07 is for.

Systems that deal in documents and evidence — reports, exports, uploads, records from other systems — converge on a pipeline shape: files land in an S3 bucket, landing triggers processing, processing produces both structured metadata (for the application to query instantly) and curated files (for analysis at leisure). The elegant trick is that S3 itself is the database for the analytical half: Athena runs SQL directly over the files, so there is no warehouse to run, size, or patch.

This “raw bucket → processed bucket → query in place” shape is a miniature data lake, and it scales from a hundred files to a hundred million without changing the picture. The raw bucket also quietly serves another purpose: it preserves the original, untouched input — which matters the moment anyone asks you to prove what was received.

Every pattern so far does things. This one remembers them — in a way that holds up when someone skeptical asks. For governance, risk, and compliance systems, the audit trail isn't a logging afterthought; it's a load-bearing feature with three hard requirements: it must be complete (every consequential action recorded), immutable (nobody — including administrators — can quietly edit history), and queryable (an auditor's question is answerable in minutes, not weeks).

The design principle: record events, not state. Don't just store “assessment #42 is approved” — store the append-only sequence of facts that got it there: submitted by whom, at when; reviewed by whom; approved on what basis. Current state is derivable from events; events are not derivable from state. And crucially, the trail has two layers: your application's events (what users did) and CloudTrail (what every IAM identity did to the infrastructure itself). Auditors will ask about both.

Notice what the security notes across seven patterns kept repeating. That's not laziness — serverless security really is a small number of moves applied consistently. AWS handles the layers below you (hypervisors, OS patching, physical security); under the shared-responsibility model, what remains yours is configuration: who can do what, to which data, and how you'd know. The good news for the security-minded: configuration is reviewable, diffable, and auditable in a way that patch levels never were.

Real systems compose these patterns rather than choosing one: a static front-end (01) calling an API (02) that queues heavy work (03), publishes events (04) that start workflows (05), over an ingestion pipeline (06), with everything writing to the audit trail (07). The skill is knowing which shape each requirement maps to:

A last thought. Diagrams like these are the easy part — any of them can be assembled in an afternoon. The durable work is in the requirements the boxes encode: what must never be lost, who must approve what, what you'd need to prove a year from now. Get those right, and the architecture mostly draws itself.