The Ladder of Altitudes

The Pareto stack is a set, but a set you read in any order is just a pile. The patterns earn their power from where they sit relative to each other. So the book gives them an order, and the order is a ladder.

The seven rungs

Start at the code and rise to where it runs. Each rung answers a different question, and each assumes the rung below it is already solid. To keep the rungs from arriving as disjointed snippets, the book climbs all seven through one familiar app: a food-delivery marketplace with three sides, the customer, the restaurant (your tenant), and the courier. Each altitude solves a real feature of that same app, so you watch the patterns compose instead of meeting them one at a time and forgetting them.

Object. How do you organise code inside a single boundary so it bends instead of breaking when requirements change? This is the Gang of Four altitude: Strategy, Adapter, Decorator, and the handful of others that survived contact with thirty years of real codebases. Here the Order moves through its lifecycle as a State machine and CourierMatchingStrategy swaps nearest for fastest without an if ladder.

Component. How do you structure one service so it stays testable and changeable? Dependency injection as the spine, a thin gateway to your data, the domain core kept clean of I/O. This is where OrderGateway sits over a stored procedure and an OrderPlaced domain event notifies the kitchen.

Data and persistence. How do you store state so it survives, scales for reads, and tells you who changed what? Multitenancy, optimistic concurrency, the event-sourcing combo for the rare case that needs it. Restaurants are the tenants, sharing one schema behind tenant_id and row-level security.

Messaging and scale. How do you move state between services without losing work when one of them falls over? Queues, competing consumers, the outbox that ties a publish to a database transaction. The dinner rush is the spike; couriers compete to pick up the next assignment off the queue.

Resilience. How do you stay up when the things you depend on don't? Retry, circuit breaker, bulkhead, timeout. The patterns that turn "the payment provider hiccuped" into a non-event, plus the idempotency that stops a retry charging the customer twice.

Observability. How do you see inside a running system, and how does it wake someone when it's genuinely in trouble? Structured logs keyed on order_id, the golden signals at rush, traces that thread one order across order, payment, and courier.

Hosting. How does all of it run somewhere without marrying one cloud? The container as the portability boundary, state pushed outside it, the same order-service image on GCP (AWS, Azure).

Object to container. Below the bottom rung there is only syntax; above the top one there is only somebody else's billing console.