The Pareto Stack: Cloud Design Patterns for Small Teams

Open any list of cloud design patterns and you start to drown. The Gang of Four catalogued 23 object-level patterns in 1994 and that book is still in print. The Azure Cloud Design Patterns catalogue adds dozens more for messaging, data, and resilience. microservices.io lists dozens again. Stack the enterprise integration patterns on top, then the persistence patterns from Fowler's PoEAA, and a working engineer with a deadline is staring at well over a hundred named things, each with a diagram and a tradeoff and a chorus of blog posts insisting it is the one you cannot ship without.

Two things happen to a small team in front of that pile. The first team reads the catalogue, panics, and reaches for everything: a message bus for three services, event sourcing for a CRUD form, a service mesh before the second deployment. They ship a distributed system they cannot operate, and the pager owns them by month two. The second team reads the catalogue, panics, and reaches for nothing: no retries, no health check, no structured logs, one connection pool quietly leaking until it falls over at 3am. Both teams lost to the same enemy. Too much choice, not enough judgement.

Completeness is the catalogue's job. Curation is yours.

This book takes the opposite bet. There is a finite, learnable set of patterns that carries software from "works on my machine" to "runs in production for years," and it is far smaller than the catalogue suggests. The book curates a small core of patterns at each of seven altitudes: object, component, data and persistence, messaging and scale, resilience, observability, and hosting. A few dozen in all, applied with judgement, that build pretty much any modern, cloud-agnostic, containerised system a small team will actually be asked to build. We call it the Pareto stack. The right twenty per cent.

To keep the patterns honest, the whole book teaches them through one running example: a food-delivery marketplace, the kind you already use to get dinner (Uber Eats, DoorDash, Deliveroo). Three sides: a customer who orders, a restaurant that cooks, a courier who delivers. Every chapter solves a real feature of that same app instead of inventing a throwaway snippet, so you watch the patterns compose rather than meet each one in isolation. The Order you meet at the object level is the same Order that gets retried under load in the resilience chapter and assembled into a reference Order Service at the end. By the last page the example is a small system, built from features you already understand because you have ordered from one.

Patterns are vocabulary, not architecture

Start with what a pattern actually is, because the catalogue obscures it. A pattern is a name for a shape you'd have arrived at anyway. "Circuit Breaker" is not an architecture; it's a word for the thing you do when you stop hammering a dead payment provider. "Strategy" is a word for swapping one behaviour for another behind a stable interface, which is exactly what CourierMatchingStrategy does when it picks the nearest courier today and the cheapest one tomorrow. The value of the name is that your teammate reads it in a pull request and knows the shape in one second, with no paragraph of explanation.

That makes patterns a shared language, not a building. You can know every word in the dictionary and still write a bad sentence. Naming the pattern does none of the design for you. You still have to decide where the boundary goes, what the failure mode is, and whether this service even needs the thing.

A pattern is a word, not a wall. You still have to design the building.

So the goal of learning patterns is fluency, not coverage. You want enough vocabulary that you can read a system, name its parts, and reach for the right shape without reinventing it. Beyond that point, more catalogue is a tax. The hundredth pattern you half-remember is not knowledge; it's a thing you'll cargo-cult into a codebase that didn't ask for it.

The selection criterion

If we're cutting the catalogue down, we need an honest rule for what stays. Here it is, and it runs through every chapter: maximum production-readiness per unit of team capacity. A pattern earns its slot by what it buys you in production, measured against what it costs you to carry. Cleverness doesn't enter into it, and neither does whatever's current this quarter. A pattern that only looks good in an architecture diagram scores below zero, because now someone has to build the diagram.

"Per unit of team capacity" is the part the catalogues leave out. A pattern that a fifty-person platform team runs without thinking can sink a team of three, because the three carry it forever. Every pattern you adopt is one you maintain. There's code to understand and infrastructure to run, and one night there's a failure mode to debug at 3am. That carrying cost is the over-engineering tax, and we'll name it for every pattern in the book. A pattern with no production payoff you can state in a sentence is not a pattern you've chosen. It's one you've cargo-culted.

This is why "what it buys you in production" is the framing for every pattern's payoff. If you can't finish the sentence "I'm adding this because in production it..." then you haven't earned the pattern yet. Curation is not us being precious. It's the only way a small team gets the value of the catalogue without the weight of it.

Maintain what you ship

The north star sits underneath the selection criterion: maintain what you ship. Production-ready is not a maximum you chase; it's a bar you clear and then keep clearing, with the same small team, a year from now, when the person who wrote the clever bit has moved on.

That single constraint reorders the whole catalogue. It promotes the boring, durable patterns (a health endpoint on the order service, a retry with backoff on the payment call, a thin OrderGateway over a stored procedure) and demotes the impressive, heavy ones (full event sourcing for a menu, a saga before you have a distributed transaction). The patterns that survive contact with a small team are the ones you can still reason about when you're tired and the incident channel is loud at the dinner rush.

Production-ready is a bar you clear, not a maximum you chase.

A finite set, then, scored by what it buys you against what it costs to carry, held to one rule: you have to be able to maintain it. That's the stack. The rest of Part I sets up how to read it, and the rest of the book climbs it.

The set only makes sense as a ladder, so that's where we start: seven altitudes, each with its own job, and a tax for climbing too high too soon.