Learning paths

Where to start in the archive

There are over 75 issues now, and reading them in the order I wrote them doesn’t make much sense. These paths group them by the problem you’re dealing with. Each one is a reading order, so start at the top and skip anything you already know.

New here? The free 5-day course is the shortest way in. After that, you get the newsletter every Sunday.

Start here if you keep getting pulled into design conversations and aren’t sure what’s expected of you. The first eight lessons are about weighing up a decision. The rest are about getting a room to agree on it.

How architects think

1. The #1 shift from developer to architect (it’s not technical)

2. Why architects don’t chase perfect designs (and what they do instead)

3. The best design decision? Not building it.

4. Tradeoffs Are the Real Deliverables

5. Architecture Without Feedback Is Just Guessing

6. “One-Way” vs. “Two-Way” Door Decisions With Speed That Doesn’t Break Things

7. Kill the Bad Ideas First

8. The Demo Is the Easiest Test You’ll Ever Pass

Getting a decision made

1. If no one understands it, it’s not architecture.

2. Your system has a story. Can you tell it?

3. The First Diagram Is Always Wrong

4. The 15-Minute ADR With Decisions That Actually Survive

5. The 30-Minute Architecture Review That Actually Ships

6. How to Write an RFC That Gets a Decision, Not Another Meeting

Read this once production becomes your problem. SLOs come first, then timeouts, retries, backpressure and circuit breakers. The last few lessons are about spotting trouble before your users report it.

1. Stability First, Then Scale

2. If Everything Is Important, Nothing Is

3. SLOs & Error Budgets: Ship With Guardrails

4. API Timeouts & Retries That Don’t Melt Your System

5. When Your Safety Net Becomes a Noose: Mastering Retry Storms

6. Backpressure Is Your Safety Net

7. Your Circuit Breaker Won’t Trip

8. Bulkhead Architecture With Failures That Stay Contained

9. Error Contracts Across Services

10. Designing Systems That Co-Exist With AI Agents: Protect Your APIs Before Non-Human Traffic Breaks Them

11. Logs Are Not Enough

12. What to Instrument Before You Write the Business Logic

13. Five Percent of Your Users Won’t Tell You Anything

For when the numbers in two places don’t agree, or an event went missing somewhere between services. It starts with queries and indexes and works up to events, sagas and tenant isolation.

1. Latency Is a Feature, But Most Teams Treat It Like a Bug

2. Queries and Indexes With Predictable Latency

3. Pagination That Doesn’t Die at Page 2000

4. Locking and Deadlocks With Fewer Surprises

5. Caching Without Regret

6. Idempotency Everywhere

7. Never Lose Another Event: The Outbox Pattern That Actually Works

8. Data Contracts for Events With Safe Evolution

9. Fat Events, Thin Events, and the Bill Nobody Saw Coming

10. Saga Pattern Failure Modes: Design Compensations That Actually Complete

11. Designing Multi-Tenant Isolation

12. The Data Leak That Never Throws an Error

Where to draw the lines between services, and why they so often end up following the org chart. If you’re about to split a monolith, or merge services back together, read this first.

1. Start with edges, not the core

2. Design for Change, Not Just Today

3. Design for Reversibility

4. Modularity Is Not About Code. It’s About Change

5. Complexity Doesn’t Disappear, You Just Move It

6. The Distributed Monolith Is Worse Than the Monolith

7. The Modular Monolith Decision Framework: When Fewer Services Beat More

8. The Abstraction Tax: When Clean Architecture Creates Operational Complexity

9. Architectural Fitness Functions: Automated Rules That Catch Drift Before Production Does

10. Assessing a Legacy System Before You Try to Replace It

11. Your Org Chart Is Your Architecture

12. Architect for the Team You Have, Not the One You Wish You Had

Start with the 48-hour bottleneck audit if delivery feels slow and nobody agrees why. Further down there’s deploying without putting every customer at risk, and the running costs that tend to get noticed late, especially for AI features.

1. The 48-Hour Bottleneck Audit: Find Your Delivery Constraint Before Management Hires a Consultant

2. Lead Time vs. Cycle Time: Find the Real Bottleneck With a 2-Hour Value Stream Map

3. Stream-Aligned Teams With Deployments That Don’t Block

4. Golden Paths (Paved Roads) Beat Tribal Knowledge

5. Eliminate “Works on My Machine” With Containerized Dev Environments

6. Shadow Traffic & Dual-Run: Prove It Before Cutover

7. How to Keep a Bad Deploy From Hitting Every Customer

8. Secret Rotation With Zero Downtime

9. The Instability Tax: What Faster Shipping Really Costs You

10. The Three Numbers That Tell You the Truth

11. AI Speeds Up the Part That Was Never Slow and the Bottleneck Just Moved Downstream

12. FinOps for Architects: Cost as a Quality Attribute

13. Where AI Actually Earns Its Keep in Your Product

14. The AI Feature That Loses Money on Your Best Customers

Seven issues on what happens when a provider you depend on fails, written with DORA and European financial services in mind. I wrote them as a run, so they read best in order.

1. You Have a Vendor List. You Don’t Have a Dependency Map.

2. Their Outage, Your Incident

3. The Component You Pinned On Purpose

4. The Managed Service That Says It’s Fine

5. Four Hours to Answer a Question You Can’t

6. Your Exit Clause Is Not an Exit Plan

7. Find the Blast Radius First

Five public postmortems from Lloyds, Coinbase and Cloudflare, all about changes that looked routine at the time. Most of them end with a check you can run against your own deploy process.

1. The Change That Threw No Errors

2. Low-Risk Is a Label

3. The Change Nobody Deployed

4. The Second Change

5. The Way Back

Get the next one on Sunday

You’ll get the free 5-day course first.