Books
Books about software architecture, engineering, and the decisions behind systems that have to work in the real world.
Beyond Microservices
Building Systems That Align Architecture, Teams, and Flow
Beyond Microservices is not a guide to splitting a system into smaller services. It is about recognizing when architecture, ownership, delivery, and operations have stopped scaling together, then using evidence to decide what should change next.
Microservices Are a Signal
When an organization starts talking about microservices, the important question is not immediately How should we split the system?
The conversation itself can be a signal that a threshold has been crossed. Coordination is slowing down. Ownership is becoming ambiguous. Releases require too many teams. The boundaries no longer match how the product or organization is changing.
Microservices are one possible response to that pressure. Sometimes the right move is decomposition. Sometimes it is a stronger contract, a different team boundary, better platform support, or consolidation. Architecture begins with diagnosing the constraint, not choosing the topology.
The Benefits Are Real. So Are the Costs.
Independent release, selective scaling, smaller blast radii, and team autonomy can create real value. But distribution does not remove complexity. It moves it.
WHAT YOU GAIN
More Options
Independent release, selective scale-out, clearer ownership, tighter failure containment, and the ability to change one part of the system without changing everything else.
WHAT YOU PAY
Distribution Tax
Network failure, tail latency, observability, schema evolution, idempotency, security, incident response, testing surface area, platform work, and coordination all become part of the bill.
The tax always gets paid. Strategy decides where to pay it.
VIA
Visualize. Isolate. Absorb.
Complexity does not disappear when a new abstraction is introduced. It moves. VIA is a way to make that movement manageable.
Visualize
Make hidden complexity observable. Look at customer journeys, P95 and P99 behavior, queues, retries, release coupling, and the places where variability actually enters the system.
Isolate
Put complexity behind boundaries where failure can stay local. Use ownership boundaries, bulkheads, pool isolation, rate limits, circuit breakers, and designs that preserve reversibility.
Absorb
Build enough resilience to take a hit without losing the system’s shape. Backpressure, load shedding, retry budgets, brownouts, error budgets, and automated rollback turn recovery into an engineered property.
Read the Signals Before the Outcome
The book separates structural signals that appear early from outcome metrics that tell you what eventually happened.
LEADING SIGNALS
See friction while options are still open.
Release Coupling Ratio
How much coordination is required before a change can actually release?
Sync Hop P95
How deep is the blocking dependency chain on a critical customer journey?
Ownership Coverage
Does every important service have clear operational accountability?
Tail Index
How far has customer-visible P99 latency drifted from the median?
OUTCOMES
Connect structure to delivery.
Deployment Frequency and Change Lead Time describe delivery speed. Change Failure Rate and MTTR show what happens when that speed meets production.
The goal is not to replace DORA metrics. It is to connect them to the architectural and organizational signals that can help explain why they move.
Make the Architecture Operable
Principles matter only when they change what the system does. The book turns architecture into contracts, policies, and executable guardrails.
Team API
Turn ownership, SLOs, on-call paths, data responsibilities, and interaction rules into an explicit contract.
Composite SLO
Put latency, reliability, cost, accuracy, and responsibility on the same decision surface instead of optimizing one dimension in isolation.
Decision Sunset
Give architectural decisions an expiry condition so a good choice from yesterday does not become an invisible constraint tomorrow.
Release ≠ Deploy
Separate moving code into production from exposing it to users. Feature flags, canaries, and rollback controls make speed reversible.
Error Budget
Make the trade between speed and reliability executable. When the budget burns too fast, the system gets the authority to slow or stop exposure.
Paved Road
Move recurring complexity into platform defaults so safe behavior becomes easier than rebuilding observability, security, resilience, and delivery controls team by team.
Speed Is Not a Free Variable
A dashboard can show more deployments while customers still wait longer for useful changes. Deployment frequency alone does not tell you whether the organization is learning faster or merely moving bits more often.
Safe speed comes from bounded exposure and reversibility: SLOs, error budgets, progressive delivery, canaries, automatic rollback, and the separation of release from deploy.
Decomposition Is Not a One-Way Door
Start with boundaries that can be tested cheaply. Validate them inside a modular monolith. Move toward selective microservices when the coordination cost clearly exceeds the cost of distribution.
And be willing to reverse direction. A boundary that once bought independence can later accumulate release coupling, synchronous hops, hub risk, and coordination overhead until consolidation becomes the better trade.
Good architecture requires both the courage to split and the courage to merge.
Decision Sunsets and Consolidation Reviews make reversibility part of the operating model instead of treating a merge as an admission that the previous design was wrong.
Built to Be Used, Not Just Read
Six appendices turn the ideas into artifacts that can be brought into real engineering work.
Team & Ownership
Team APIs, ownership maps, RAPID/RACI matrices
Reliability & Operations
SLO catalogs, error budget policies, incident playbooks, postmortems
Release & Deployment
Release ≠ Deploy checklists, feature flag policies, canary and rollback configurations
Architecture Decisions
ADRs with Decision Sunsets, consistency profiles, trade-off ledgers
Code & Configuration
Outbox and idempotency examples, retry and timeout policies, PromQL, SQL, YAML, and JSON
Workshop Guides
EventStorming, failure-mode analysis, Bow-Tie, and Game Day facilitation
The Question Behind the Book
The tools will change. Service frameworks will change. AI will move boundaries again. The harder problem is keeping architecture, ownership, delivery, reliability, and economics aligned while the system evolves.
How do we design architecture, teams, and operating practices so they can evolve together?
Beyond Microservices
Building Systems That Align Architecture, Teams, and Flow