Library

Wrap a call to a remote dependency in a switch that opens after repeated failures, so callers fail fast and the struggling dependency gets room to recover instead of a stampede.

When · When a slow or failing downstream service would otherwise tie up threads and cascade; costs a fallback path and tuned thresholds.

Reference ↗related DP-020

• BC-720.40Integration & API Delivery
• BC-1230Site Reliability

Repeat a failed call a bounded number of times with growing, jittered delays, so transient faults heal themselves without synchronized retries making them worse.

When · Only for idempotent operations and transient errors; pair with a circuit breaker and a deadline, or retries become a self-inflicted outage.

Reference ↗related DP-010

• BC-720.40Integration & API Delivery
• BC-1230Site Reliability

Partition a system's resources (thread pools, connections, instances) by consumer or dependency, so one misbehaving tenant or slow downstream exhausts only its own compartment and the rest keep serving.

When · When one noisy workload or dependency can starve everything else; costs idle capacity in each compartment and a sizing decision per partition.

Reference ↗related DP-010DP-040

• BC-720.10.30Non-Functional Design
• BC-1230.40Resilience & Capacity Engineering

Cap how many requests a caller may make in a window and reject or queue the excess with a clear signal, so a shared service protects its own capacity and treats tenants fairly.

When · Any API exposed to many clients or to the public; costs a policy for who gets how much, and clients that know how to back off when told.

Reference ↗related DP-020DP-050DP-110

• BC-1240.10API Design & Governance
• BC-1250.30.20Usage Aggregation & Quotas

Let a service shed or degrade lower-priority work when it approaches its limits, instead of accepting every request and failing all of them at once.

When · When demand can exceed capacity faster than it can scale; costs an explicit ranking of what to drop first and a degraded mode that still makes sense to users.

Reference ↗related DP-040DP-060

• BC-1230.40Resilience & Capacity Engineering
• BC-720.10.30Non-Functional Design

Put a queue between producers and a slower consumer so bursts are absorbed and the consumer runs at a steady pace it can sustain, rather than being sized for the peak.

When · When arrival rate is spiky but work can tolerate a short delay; costs a queue to operate and an answer for what happens when the backlog grows faster than it drains.

Reference ↗related DP-050DP-100

• BC-720.40.20Event & Messaging Integration
• BC-1210.20.20Event Streaming & Queues

The application checks a cache first, loads from the system of record on a miss, and writes the result back into the cache, keeping the cache a disposable copy rather than a second source of truth.

When · Read-heavy data that tolerates brief staleness; costs an invalidation strategy, and gets dangerous when the cache quietly becomes the only place a value lives.

Reference ↗related DP-090

• BC-720.10.30Non-Functional Design
• BC-1210.20.10Managed Datastores

Split one logical dataset across several stores by a key, so write volume, storage and hot spots are spread instead of concentrated in a single database.

When · When a single database can no longer hold the data or the write rate; costs cross-shard queries, rebalancing when a key gets hot, and a key choice that is hard to change later.

Reference ↗related DP-090DP-270

• BC-750.20.20Data Platform Design
• BC-1210.20.10Managed Datastores

Copy a primary database to one or more replicas that serve read traffic, so reporting and browse workloads stop competing with writes on the primary.

When · When reads dwarf writes and slightly stale results are acceptable; costs replication lag that the application must account for, especially right after a write.

Reference ↗related DP-070DP-080DP-270

• BC-1210.20.10Managed Datastores
• BC-730.40Storage, Backup & Recovery

Several identical workers pull from the same queue, so throughput scales by adding workers and a failed worker's message is simply picked up by another.

When · Independent units of work that can run in any order; costs idempotent processing and, where ordering matters, partitioning so related messages land on one consumer.

Reference ↗related DP-060DP-180

• BC-720.40.20Event & Messaging Integration
• BC-1210.10.20Workload Scheduling & Scaling

A single entry point in front of many backend services that handles routing, authentication, rate limits and protocol translation, so each service does not reimplement the edge.

When · As soon as more than a handful of services face external clients; costs a component that can become a bottleneck or a dumping ground for business logic if left unguarded.

Reference ↗related DP-040DP-120DP-360

• BC-720.40.10API Design & Build
• BC-1240.10API Design & Governance

Give each client type (web, mobile, partner) its own thin backend that shapes and aggregates data for that experience, instead of one general-purpose API that serves everyone poorly.

When · When clients differ enough that one API shape forces chatty calls or over-fetching; costs one more deployable per client and duplicated aggregation logic to keep honest.

Reference ↗related DP-110DP-150

• BC-720.40.10API Design & Build
• BC-720.10.20Interface & Data Design

Producers publish events to a topic without knowing who listens; any number of subscribers receive each event independently, so adding a consumer never requires changing the producer.

When · When several systems need to react to the same fact; costs event contracts that must be versioned, and the loss of a direct answer to the question "did anyone handle this".

Reference ↗related DP-140DP-230DP-310

• BC-720.40.20Event & Messaging Integration
• BC-1210.20.20Event Streaming & Queues

Carry a request over messaging and route the answer back on a reply channel keyed by a correlation id, getting a synchronous-style interaction with the buffering and decoupling of a queue.

When · When a caller needs an answer but the provider should not be called directly; costs correlation bookkeeping, timeouts and a plan for replies that never arrive.

Reference ↗related DP-130DP-150

• BC-720.40.20Event & Messaging Integration

Broadcast one request to several providers in parallel, then combine their responses into one result, typically with a deadline so a slow participant does not hold the answer hostage.

When · Price checks, searches or availability lookups across many sources; costs aggregation rules for partial results and clear handling of the provider that never answers.

Reference ↗related DP-140DP-120

• BC-720.40.20Event & Messaging Integration
• BC-720.10.20Interface & Data Design

Inspect each message and send it to the right destination based on its content, so senders do not need to know which of several systems owns a given case.

When · When the same message type is handled by different systems depending on region, product line or customer segment; costs routing rules that need an owner and a test suite.

Reference ↗related DP-130DP-170

• BC-720.40.30Integration Platform Configuration
• BC-720.40.20Event & Messaging Integration

Store a large payload in shared storage and pass only a reference through the messaging system, so brokers stay fast and message size limits stop shaping the design.

When · Documents, images or bulk records moving through an event pipeline; costs a storage lifecycle for the payloads and a consumer that knows how to redeem the reference.

Reference ↗related DP-160DP-130

• BC-720.40.20Event & Messaging Integration
• BC-730.40.10Storage Provisioning

A consumer records the ids of messages it has already processed and ignores repeats, so at-least-once delivery does not create duplicate orders, payments or notifications.

When · Any consumer behind a broker that may redeliver; costs a deduplication store with a retention window and a message id that producers assign consistently.

Reference ↗related DP-100DP-290DP-020

• BC-720.40.20Event & Messaging Integration
• BC-720.20.10Application Development

Put a routing layer in front of a legacy system and move one capability at a time to a new implementation behind it, until the old system serves nothing and can be switched off.

When · Replacing a large system where a single cutover is too risky; costs running both systems for a long time and discipline to finish, since half-strangled systems are the usual outcome.

Reference ↗related DP-200DP-110

• BC-170.30.10Application Portfolio Rationalization
• BC-720.60.40Application Decommissioning

A translation layer between your model and an external or legacy system's model, so foreign concepts and quirks are converted at the boundary instead of leaking into your core.

When · Integrating with a system whose model you do not control and do not want to inherit; costs a mapping layer that must evolve with both sides.

Reference ↗related DP-190DP-210

• BC-720.10.20Interface & Data Design
• BC-720.40.10API Design & Build

Draw an explicit boundary inside which a domain model and its language are consistent, and accept that the same word ("customer", "order") can legitimately mean different things in different contexts.

When · When one enterprise-wide model keeps collapsing under conflicting definitions; costs explicit contracts and translation between contexts rather than one shared schema.

Reference ↗related DP-200DP-220DP-240

• BC-720.10.10Solution Architecture
• BC-750.20.10Enterprise Data Modeling
• BC-170.30.30Reference Architecture

A cluster of domain objects treated as one unit for changes, with a single root that enforces its invariants, so consistency rules live in one place and transactions have a natural size.

When · When business rules span several objects that must change together; costs careful boundary sizing, since aggregates that are too large serialize everything and too small cannot enforce the rule.

Reference ↗related DP-210DP-230DP-260

• BC-720.10.20Interface & Data Design
• BC-720.20.10Application Development

Record things that happened in the business ("Order Placed", "Invoice Paid") as first-class, named, immutable facts, so other parts of the system react to them rather than polling state.

When · When side effects pile up inside commands or other teams need to know what happened; costs naming discipline and a decision about which events are internal and which are published contracts.

Reference ↗related DP-130DP-220DP-260

• BC-720.10.20Interface & Data Design
• BC-720.40.20Event & Messaging Integration

One deployable unit built from modules with enforced boundaries and explicit interfaces, keeping the operational simplicity of a monolith while preserving the option to extract a service later.

When · Small to mid-sized teams who want clean boundaries without distributed-systems overhead; costs tooling to enforce module boundaries, since a monolith with no fences is just a big ball.

Reference ↗related DP-210DP-250

• BC-720.10.10Solution Architecture
• BC-720.20.20Engineering Standards & Code Review

Keep the domain logic in the center and reach the outside world (databases, queues, UIs, other services) only through ports and adapters, so infrastructure can be swapped or faked without touching the core.

When · When business logic is worth testing in isolation and infrastructure choices may change; costs more interfaces and indirection than a simple CRUD application needs.

Reference ↗related DP-240DP-200

• BC-720.20.20Engineering Standards & Code Review
• BC-720.10.10Solution Architecture

Persist every change as an appended event and rebuild current state by replaying them, so the full history is the source of truth and any past state can be reconstructed.

When · When audit, temporal queries or replay matter more than simplicity; costs event versioning, snapshotting for performance, and a learning curve the whole team pays.

Reference ↗related DP-270DP-230DP-220

• BC-750.20.20Data Platform Design
• BC-720.10.20Interface & Data Design

Separate the model that handles writes from the models that serve reads, so each can be shaped and scaled for its job instead of one schema compromising for both.

When · When read and write workloads diverge sharply or reads need many denormalized views; costs eventual consistency between the two sides and more moving parts to operate.

Reference ↗related DP-260DP-090DP-300

• BC-720.10.20Interface & Data Design
• BC-750.20.20Data Platform Design

Run a business transaction across several services as a sequence of local transactions, each with a compensating action that undoes it if a later step fails.

When · When a workflow spans services that cannot share a database transaction; costs compensation logic for every step and acceptance that intermediate states are visible.

Reference ↗related DP-290DP-180DP-230

• BC-720.10.20Interface & Data Design
• BC-720.40.20Event & Messaging Integration

Write the business change and the event to publish in the same database transaction, then have a relay publish from the outbox table, so state and messages never disagree.

When · Whenever a service both updates its database and emits events; costs a relay process and an outbox table to prune, which is still cheaper than a lost or phantom event.

Reference ↗related DP-300DP-180DP-280

• BC-720.40.20Event & Messaging Integration
• BC-750.30.10Data Ingestion

Read a database's transaction log and stream each insert, update and delete as an event, so downstream systems follow the source without batch extracts or application changes.

When · Feeding analytics, caches or search from a system you cannot modify; costs log access on the source, schema-change handling, and events that describe rows rather than business meaning.

Reference ↗related DP-290DP-310DP-330

• BC-750.30.10Data Ingestion
• BC-750.30.30Pipeline Operations

Keep every event and message schema in a central, versioned registry with compatibility rules enforced at publish time, so a producer cannot silently break its consumers.

When · Any streaming platform with more than one team producing or consuming; costs a registry to run and compatibility rules that make some schema changes slower on purpose.

Reference ↗related DP-130DP-300

• BC-1240.10.40Webhooks & Event Contracts
• BC-750.10.20Data Policy & Standards

Treat analytical data as products owned by the domains that know it, served on a shared self-service platform under federated governance, instead of one central team owning every pipeline.

When · Large organizations where the central data team is the bottleneck; costs real ownership in each domain and a platform good enough that teams do not each build their own.

Reference ↗related DP-330DP-210DP-480

• BC-750.10.10Data Ownership & Stewardship
• BC-750.20.20Data Platform Design

Land raw data unchanged, refine it into cleaned and conformed tables, then publish curated, business-ready sets, so each layer has a known quality level and lineage back to the source.

When · Building an analytics platform on open table formats over object storage; costs storage for every layer and discipline about which layer consumers are allowed to read.

Reference ↗related DP-320DP-300

• BC-750.30.20Data Transformation
• BC-750.20.20Data Platform Design

Grant no access based on network location; every request is authenticated, authorized and encrypted against the identity of the user and device, with policy evaluated continuously rather than once at login.

When · Hybrid workforces, cloud estates and any system where the perimeter no longer exists; costs strong identity everywhere first, and a long migration from network-based controls.

Reference ↗related DP-360DP-430DP-350

• BC-760.20Identity & Access Management
• BC-760.40.30Network Security Controls

Keep credentials, keys and tokens in a dedicated vault that issues them at runtime, rotates them, and logs every access, so no secret lives in source code, config files or a chat thread.

When · From the first deployed service onward; costs a vault to operate and an application bootstrap that can authenticate to it without a secret of its own.

Reference ↗related DP-340DP-410

• BC-760.50.30Encryption & Key Management
• BC-760.20.40Privileged Access Management

Delegate authentication to a trusted identity provider and accept its signed tokens, so applications never handle passwords and users sign in once across many systems.

When · Any application with users who already have a corporate or social identity; costs a dependency on the provider's availability and careful validation of the tokens it issues.

Reference ↗related DP-340DP-110

• BC-760.20.20Authentication
• BC-1250.40.10Single Sign-On Integration

Run two identical production environments, deploy to the idle one, verify it, then switch traffic over in one move, keeping the old environment ready for an instant rollback.

When · Releases where downtime or a slow rollback is unacceptable; costs double the infrastructure during the switch and a plan for database changes that both versions must tolerate.

Reference ↗related DP-380DP-400

• BC-1220.30.40Blue-Green & Traffic Shifting
• BC-720.50.30Deployment Automation

Send a small slice of real traffic to the new version, watch its error rate and latency against the old one, and widen the slice only while the signals stay healthy.

When · When production is the only environment that reveals the problem; costs traffic-splitting infrastructure, comparable metrics, and automated rollback when the canary fails.

Reference ↗related DP-370DP-390DP-470

• BC-1220.30.20Canary & Ring Rollout
• BC-1230.20.20Alerting & Signal Design

Separate deploying code from releasing a feature by wrapping it in a runtime switch, so unfinished work can ship dark and a bad feature can be turned off without a redeploy.

When · Trunk-based development and gradual rollouts; costs flag hygiene, since every flag left behind is a branch in production that nobody tests.

Reference ↗related DP-380DP-370

• BC-1220.30.10Feature Flag Management
• BC-1260.30.20Assignment & Exposure Tracking

Never modify a running server or image; every change builds a new artifact that replaces the old one, so what runs in production is exactly what was built and tested.

When · Containers, machine images and anything that can be rebuilt from source; costs a fast build pipeline and giving up the habit of fixing things by hand on the box.

Reference ↗related DP-410DP-370DP-440

• BC-730.60.10Infrastructure as Code
• BC-1210.30.30Artifact & Image Registry

Declare networks, compute, storage and permissions in version-controlled files and apply them with a tool, so environments are reproducible, reviewable and diffable like any other code.

When · Every cloud environment that will exist longer than a day; costs state management, a review process for infrastructure changes, and resisting the console when it is faster.

Reference ↗related DP-400DP-350

• BC-730.60.10Infrastructure as Code
• BC-730.20.10Landing Zone Design

Deploy a helper process next to the application in the same unit, handling concerns like proxying, logging or secrets, so those capabilities arrive without being compiled into every service in every language.

When · Polyglot estates where a shared library is impractical; costs one more process per instance and a platform that understands the pairing.

Reference ↗related DP-430DP-450

• BC-730.10.20Container Platform Operations
• BC-1210.10Compute & Runtime Platform

Move service-to-service networking (mutual TLS, retries, timeouts, traffic splitting, telemetry) out of application code and into a layer of proxies managed by a control plane.

When · Dozens of services where consistent security and traffic policy matter; costs operational complexity and latency that a small estate will never recoup.

Reference ↗related DP-420DP-340DP-380

• BC-730.10.20Container Platform Operations
• BC-760.40.30Network Security Controls

A set of conventions for services that run well on cloud platforms: configuration from the environment, stateless processes, dependencies declared, logs as streams, disposable instances.

When · Any new service meant for a container or serverless platform; costs externalizing state and configuration, which legacy code written for a single server resists.

Reference ↗related DP-400DP-460DP-350

• BC-720.20.20Engineering Standards & Code Review
• BC-1210.10Compute & Runtime Platform

Propagate a trace id across every hop of a request and record timed spans in each service, so one slow user action can be followed through the whole system instead of guessed at from separate logs.

When · Any request that crosses more than two services; costs instrumentation in every service and a backend to store and query traces, with sampling once volume grows.

Reference ↗related DP-460DP-420

• BC-1230.20.10Telemetry Collection
• BC-730.60.30Observability Platform

Emit log events as machine-readable records with consistent fields (timestamp, level, service, trace id, tenant) rather than free text, so logs can be queried and correlated instead of grepped.

When · From the first service onward; costs agreeing on field names across teams and keeping sensitive values out of the fields people are most tempted to log.

Reference ↗related DP-450DP-440

• BC-1230.20.10Telemetry Collection
• BC-730.60.30Observability Platform

Define a measurable target for user-facing reliability, and treat the gap between that target and perfection as a budget the team may spend on change; when it is exhausted, reliability work takes priority.

When · When "is it reliable enough" keeps being argued from anecdotes; costs honest measurement and leadership willing to honor the budget when a release date is at stake.

Reference ↗related DP-380DP-450

• BC-1230.10Service Level Management
• BC-740.50.20Availability & Performance Measurement

Organize most teams around a continuous flow of work for one product or user journey, supported by platform, enabling and complicated-subsystem teams, so ownership and delivery sit in one place.

When · When handoffs between component teams dominate lead time; costs a real platform team and a reorganization that leadership must hold through the awkward period.

Reference ↗related DP-320DP-210DP-490

• BC-710.10.20Operating Model Design
• BC-1210.40Service Scaffolding & Self-Service

Run internal projects the way healthy open-source projects run: visible repositories, documented contribution paths, and maintainers who review pull requests from any team.

When · When shared components are blocked on one team's backlog; costs maintainer time for review and the cultural shift from "ask them" to "send a change".

Reference ↗related DP-480DP-500

• BC-720.20.20Engineering Standards & Code Review
• BC-1210.30.10Source Control & Repository Standards
• BC-1280.30.30Employee Contribution Policy

Capture each significant decision as a short, dated document stating the context, the options, the choice and its consequences, kept next to the code so the reasoning survives the people who made it.

When · Every project with more than one architect or a lifespan over a year; costs a few paragraphs per decision and the habit of writing them before the decision calcifies.

Reference ↗related DP-510DP-490

• BC-170.40.30Repository Stewardship
• BC-720.10.40Design Review & Sign-Off

Express architectural qualities (dependency direction, latency budgets, coupling limits) as automated checks that run in the pipeline, so the architecture is guarded continuously rather than reviewed once.

When · When review boards cannot keep up with the rate of change; costs choosing a few measurable qualities and accepting that the unmeasured ones still need a human.

Reference ↗related DP-500DP-240

• BC-170.40.10Architecture Review
• BC-720.20.20Engineering Standards & Code Review

Fundamentals of Software Architecture

An Engineering Approach

Mark Richards, Neal Ford · 2020

The clearest modern statement that architecture is trade-off analysis, with a vocabulary of styles and characteristics you can use in a review the next day.

• BC-170.30Application & Technology Architecture
• BC-720.10Solution Design

Software Architecture: The Hard Parts

Modern Trade-Off Analyses for Distributed Architectures

Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani · 2021 · ISBN 9781492086895

Picks up where Fundamentals leaves off and works through the decisions that have no clean answer: where to cut a service, who owns the data, and how to document the trade-off you chose.

patterns DP-280DP-500DP-240

• BC-170.30Application & Technology Architecture
• BC-720.10Solution Design
• BC-750.20Data Architecture & Modeling

Clean Architecture

A Craftsman's Guide to Software Structure and Design

Robert C. Martin · 2017 · ISBN 9780134494166

The dependency rule in one book: business rules in the middle, frameworks and databases at the edge. Useful as a shared vocabulary even when a team does not adopt every layer.

patterns DP-250

• BC-720.10Solution Design
• BC-720.20Software Engineering

A Philosophy of Software Design

John Ousterhout · 2018 · 2nd edition 2021

A short, opinionated case that complexity is the enemy and deep modules are the cure. The best book to hand an engineer who is about to design their first interface that others will depend on.

• BC-720.10Solution Design
• BC-720.20Software Engineering

Patterns of Enterprise Application Architecture

Martin Fowler · 2002 · ISBN 9780321127426

The pattern names most enterprise codebases are built from, whether or not anyone read the book. Still the reference when a team argues about repositories, units of work, or where the domain logic lives.

• BC-720.10Solution Design
• BC-720.20Software Engineering

Building Evolutionary Architectures

Automated Software Governance

Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage · 2017 · 2nd edition 2022

Turns architecture governance from a review board into executable fitness functions. The practical answer to how a standard stays enforced after the architect leaves the room.

patterns DP-510DP-500

• BC-170.40Architecture Governance
• BC-720.30Quality Engineering & Testing

Software Architecture in Practice

Len Bass, Paul Clements, Rick Kazman · 1998 · 4th edition 2021

The textbook treatment of quality attributes and the tactics that achieve them. Dry, but it is where the discipline of stating a requirement as a measurable scenario comes from.

• BC-170.30Application & Technology Architecture
• BC-720.10Solution Design

Software Engineering at Google

Lessons Learned from Programming Over Time

Titus Winters, Tom Manshreck, Hyrum Wright · 2020 · ISBN 9781492082798

Software engineering as programming integrated over time and people. Worth reading for the chapters on code review, dependency management, and deprecation, which apply well below Google's scale.

patterns DP-490

• BC-720.20Software Engineering
• BC-720.60Application Maintenance

The Pragmatic Programmer

Your Journey to Mastery

David Thomas, Andrew Hunt · 1999 · 20th anniversary edition 2019 · ISBN 9780135957059

The habits that separate engineers who ship maintainable systems from those who do not, in short numbered tips. Architects quote it more than they admit.

• BC-720.20Software Engineering

Documenting Software Architectures

Views and Beyond

Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford · 2002 · 2nd edition 2010

How to write an architecture down so a reader who was not in the meeting can use it: views, view packets, and what each stakeholder needs. Heavier than most teams want, but the view discipline carries over.

patterns DP-500

• BC-170.30Application & Technology Architecture
• BC-170.40Architecture Governance

Release It!

Design and Deploy Production-Ready Software

Michael T. Nygard · 2007 · 2nd edition 2018

Where the stability patterns come from. Read it before the first production incident, not after.

patterns DP-010DP-020

• BC-1230Site Reliability
• BC-740.20Incident & Problem Management

Designing Data-Intensive Applications

The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Martin Kleppmann · 2017 · ISBN 9781449373320

The one book to read on how storage, replication, consensus, and stream processing actually behave under failure. It replaces a shelf of vendor documentation with the ideas underneath.

patterns DP-080DP-090DP-300

• BC-750.20Data Architecture & Modeling
• BC-750.30Data Engineering & Pipelines
• BC-1210.20Data & Messaging Platform

Building Microservices

Designing Fine-Grained Systems

Sam Newman · 2015 · 2nd edition 2021

The balanced account of what microservices cost as well as what they buy, with a strong emphasis on organizational fit. The second edition is the one to read.

patterns DP-010DP-020DP-190

• BC-720.10Solution Design
• BC-720.40Integration & API Delivery
• BC-1230.40Resilience & Capacity Engineering

Monolith to Microservices

Evolutionary Patterns to Transform Your Monolith

Sam Newman · 2019 · ISBN 9781492047841

Incremental decomposition without a big-bang rewrite: strangler fig, parallel run, and the hard problem of splitting a shared database. Read before any modernization business case.

patterns DP-190DP-200DP-240

• BC-720.10Solution Design
• BC-720.60Application Maintenance
• BC-180.40Transformation Program Leadership

Microservices Patterns

With Examples in Java

Chris Richardson · 2018 · ISBN 9781617294549

A pattern-language view of service decomposition, sagas, API composition, and transactional messaging. Most useful when a team needs a named option for a data-consistency problem.

patterns DP-280DP-290DP-110

• BC-720.10Solution Design
• BC-720.40Integration & API Delivery

Enterprise Integration Patterns

Designing, Building, and Deploying Messaging Solutions

Gregor Hohpe, Bobby Woolf · 2003 · ISBN 9780321200686

The vocabulary every integration platform borrows: channels, routers, translators, endpoints. Still the reference for reasoning about a message flow regardless of which broker carries it.

patterns DP-130DP-160DP-170

• BC-720.40Integration & API Delivery
• BC-1210.20Data & Messaging Platform

Designing Distributed Systems

Patterns and Paradigms for Scalable, Reliable Services

Brendan Burns · 2018

Container-level patterns (sidecar, ambassador, adapter) and the multi-node patterns built on them, written by one of the people who shaped Kubernetes. Short and concrete.

patterns DP-420DP-150

• BC-1210.10Compute & Runtime Platform
• BC-720.10Solution Design

The Art of Scalability

Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise

Martin L. Abbott, Michael T. Fisher · 2009 · 2nd edition 2015

Scalability as a problem of people and process as much as technology, with the scale cube as the model for splitting load. Dated in places, but the organizational chapters hold up.

patterns DP-080DP-090

• BC-1230.40Resilience & Capacity Engineering
• BC-710.10Technology Strategy & Operating Model

Domain-Driven Design

Tackling Complexity in the Heart of Software

Eric Evans · 2003 · ISBN 9780321125217

The origin of bounded contexts, ubiquitous language, and aggregates. Read the strategic design chapters first; they matter more to an architect than the tactical patterns.

patterns DP-210DP-220DP-200

• BC-170.20Business Architecture
• BC-720.10Solution Design
• BC-750.20Data Architecture & Modeling

Implementing Domain-Driven Design

Vaughn Vernon · 2013 · ISBN 9780321834577

The companion that shows what Evans's ideas look like in code and in a team, including context mapping between systems that were never designed together.

patterns DP-220DP-230DP-250

• BC-720.10Solution Design
• BC-720.20Software Engineering

Learning Domain-Driven Design

Aligning Software Architecture and Business Strategy

Vlad Khononov · 2021 · ISBN 9781098100131

The most approachable entry to DDD, with a clear link from subdomain type (core, supporting, generic) to the architecture and the level of investment each deserves.

patterns DP-210DP-270DP-260

• BC-170.20Business Architecture
• BC-720.10Solution Design

Domain Modeling Made Functional

Tackle Software Complexity with Domain-Driven Design and F#

Scott Wlaschin · 2018

Shows how to make illegal states unrepresentable with types, so the domain model documents its own rules. The language is F#, but the modeling approach transfers to any typed language.

patterns DP-220DP-230

• BC-720.10Solution Design
• BC-720.20Software Engineering

Data Mesh

Delivering Data-Driven Value at Scale

Zhamak Dehghani · 2022 · ISBN 9781492092391

The argument for domain-owned data products over a central lake, and what federated governance has to look like for that to work. Read critically; the operating-model cost is real.

patterns DP-320

• BC-750.10Data Governance & Stewardship
• BC-750.20Data Architecture & Modeling
• BC-750.30Data Engineering & Pipelines

Fundamentals of Data Engineering

Plan and Build Robust Data Systems

Joe Reis, Matt Housley · 2022 · ISBN 9781098108304

A tool-agnostic map of the data engineering lifecycle, from ingestion to serving, with the undercurrents (security, data management, orchestration) that every stage shares.

patterns DP-330DP-300

• BC-750.30Data Engineering & Pipelines
• BC-750.20Data Architecture & Modeling

Streaming Systems

The What, Where, When, and How of Large-Scale Data Processing

Tyler Akidau, Slava Chernyak, Reuven Lax · 2018

Event time versus processing time, windows, triggers, and watermarks, explained once and properly. Required before designing anything that claims to be real-time.

patterns DP-130DP-100

• BC-750.30Data Engineering & Pipelines
• BC-1210.20Data & Messaging Platform

Database Internals

A Deep Dive into How Distributed Data Systems Work

Alex Petrov · 2019 · ISBN 9781492040347

Storage engines in the first half, distributed consensus and replication in the second. The book to read when a database choice has to be defended on more than a benchmark.

patterns DP-080DP-090

• BC-750.20Data Architecture & Modeling
• BC-1210.20Data & Messaging Platform

Kubernetes Patterns

Reusable Elements for Designing Cloud Native Applications

Bilgin Ibryam, Roland Huss · 2019 · 2nd edition 2023

The patterns a platform team should standardize before the first workload lands: health probes, resource limits, configuration, and the controller and operator patterns behind self-healing.

patterns DP-420DP-400

• BC-1210.10Compute & Runtime Platform
• BC-730.20Cloud Platform Operations

Cloud Native Patterns

Designing Change-Tolerant Software

Cornelia Davis · 2019 · ISBN 9781617294297

What an application has to do differently when its infrastructure is expected to change underneath it: statelessness, configuration, service discovery, and request resilience.

patterns DP-020DP-440

• BC-720.10Solution Design
• BC-730.20Cloud Platform Operations

Infrastructure as Code

Dynamic Systems for the Cloud Age

Kief Morris · 2016 · 2nd edition 2020

Treats infrastructure definitions as a codebase with the same expectations of testing, modularity, and pipelines. Good at explaining why a working script is not yet a platform.

patterns DP-410DP-400

• BC-730.60Infrastructure Automation & Observability
• BC-1210.30Build & Delivery Tooling

Observability Engineering

Achieving Production Excellence

Charity Majors, Liz Fong-Jones, George Miranda · 2022 · ISBN 9781492076445

Why high-cardinality structured events beat dashboards of pre-aggregated metrics when the question is one nobody anticipated. Shapes what a platform should emit, not just what it should chart.

patterns DP-450DP-460

• BC-1230.20Observability
• BC-730.60Infrastructure Automation & Observability

Accelerate

The Science of Lean Software and DevOps

Nicole Forsgren, Jez Humble, Gene Kim · 2018 · ISBN 9781942788331

The research behind the four delivery metrics and the practices that move them. The book to cite when a leadership audience asks for evidence rather than opinion.

patterns DP-390DP-480

• BC-720.50Release & Deployment
• BC-710.50Technology Value & Performance
• BC-180.30Delivery Governance

Continuous Delivery

Reliable Software Releases through Build, Test, and Deployment Automation

Jez Humble, David Farley · 2010 · ISBN 9780321601919

The deployment pipeline, defined. Older tooling in the examples, but the principles behind every modern CI/CD platform are laid out here first.

patterns DP-370DP-390

• BC-720.50Release & Deployment
• BC-1210.30Build & Delivery Tooling
• BC-1220.20Environment Promotion

The Phoenix Project

A Novel About IT, DevOps, and Helping Your Business Win

Gene Kim, Kevin Behr, George Spafford · 2013 · ISBN 9780988262591

A novel, which is why non-technical leaders will finish it. It makes work in process, constraints, and unplanned work visible in a way a slide deck cannot.

• BC-710.10Technology Strategy & Operating Model
• BC-740.30Change Enablement
• BC-190.40Continuous Improvement

The DevOps Handbook

How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Gene Kim, Jez Humble, Patrick Debois, John Willis · 2016 · 2nd edition 2021

The practitioner companion to The Phoenix Project: the three ways, flow, feedback, and continual learning, with case studies for each practice.

patterns DP-380DP-390

• BC-720.50Release & Deployment
• BC-1220.20Environment Promotion
• BC-710.10Technology Strategy & Operating Model

Site Reliability Engineering

How Google Runs Production Systems

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy · 2016 · ISBN 9781491929124

Where SLOs, error budgets, and blameless postmortems come from. Take the principles and leave the scale; most organizations need the chapters on toil and on-call, not the ones on planet-scale systems.

patterns DP-470DP-460

• BC-1230.10Service Level Management
• BC-1230.30Incident Response
• BC-740.50Service Level & Performance

Docs for Developers

An Engineer's Field Guide to Technical Writing

Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, Heidi Waterhouse · 2021 · ISBN 9781484272169

A practical process for documentation that engineers will actually follow, from reader research to maintenance. Useful for anyone who owns an API, a platform, or an architecture repository.

• BC-1240.30Developer Portal & Documentation
• BC-720.60Application Maintenance

Chaos Engineering

System Resiliency in Practice

Casey Rosenthal, Nora Jones · 2020 · ISBN 9781492043867

Experiments against production as a discipline rather than a stunt, including how to get the organization to agree to them. Pairs well with the resilience patterns in this catalog.

patterns DP-010DP-030

• BC-1230.40Resilience & Capacity Engineering
• BC-830.50Exercising & Continuous Improvement

Threat Modeling

Designing for Security

Adam Shostack · 2014 · ISBN 9781118809990

The standard text on asking what can go wrong before the design is finished, with STRIDE as the working checklist. Makes security review something an architect can run, not just request.

patterns DP-340

• BC-760.50Application & Data Security
• BC-720.10Solution Design
• BC-1270.30Product Security Engineering

Security Engineering

A Guide to Building Dependable Distributed Systems

Ross Anderson · 2001 · 3rd edition 2020 · ISBN 9781119642787

The broadest single treatment of how systems fail against adversaries, from protocols to economics to human factors. Long; use it as a reference rather than a read-through.

• BC-760.10Security Governance & Risk
• BC-760.50Application & Data Security

Building Secure and Reliable Systems

Best Practices for Designing, Implementing, and Maintaining Systems

Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield · 2020 · ISBN 9781492083122

Makes the case that security and reliability are the same engineering problem and should share design principles, controls, and incident practice. The least-privilege and recovery chapters are the payoff.

patterns DP-350DP-340

• BC-760.20Identity & Access Management
• BC-1230.50Operational Readiness
• BC-760.40Infrastructure & Endpoint Protection

Zero Trust Networks

Building Secure Systems in Untrusted Networks

Evan Gilman, Doug Barth · 2017 · 2nd edition 2024

What zero trust means once the marketing is removed: identity for every user, device, and workload, and policy enforced per request. Helps separate the architecture from the products sold under the label.

patterns DP-340DP-360

• BC-760.20Identity & Access Management
• BC-760.40Infrastructure & Endpoint Protection
• BC-730.30Network & Connectivity

Team Topologies

Organizing Business and Technology Teams for Fast Flow

Matthew Skelton, Manuel Pais · 2019 · ISBN 9781942788812

Four team types, three interaction modes, and the idea that team cognitive load is an architectural constraint. The vocabulary most platform and product org designs now use.

patterns DP-480

• BC-310.30Organization Design
• BC-710.10Technology Strategy & Operating Model
• BC-1210.40Service Scaffolding & Self-Service

Thinking in Systems

A Primer

Donella H. Meadows · 2008 · ISBN 9781603580557

Stocks, flows, feedback loops, and leverage points, from outside the software field entirely. The mental model behind why most enterprise interventions push in the wrong place.

• BC-170.10Architecture Strategy & Principles
• BC-190.40Continuous Improvement

An Elegant Puzzle

Systems of Engineering Management

Will Larson · 2019 · ISBN 9781732265189

Engineering management treated as a set of systems to tune: team sizing, migrations, and how to run a reorganization without breaking delivery. The migrations chapter alone is worth it for an architect.

• BC-310.30Organization Design
• BC-180.40Transformation Program Leadership

Staff Engineer

Leadership Beyond the Management Track

Will Larson · 2021

What senior technical roles actually do day to day, including the architect archetype, and how to get influence without authority. Honest about the parts of the job that are mostly writing and waiting.

• BC-340.50Promotion & Internal Mobility
• BC-170.10Architecture Strategy & Principles

The Manager's Path

A Guide for Tech Leaders Navigating Growth and Change

Camille Fournier · 2017 · ISBN 9781491973899

One chapter per rung from tech lead to CTO, which makes it the fastest way for an architect to understand what their engineering-management counterparts are being measured on.

• BC-340.50Promotion & Internal Mobility
• BC-330.40Leadership & Career Development

Escaping the Build Trap

How Effective Product Management Creates Real Value

Melissa Perri · 2018 · ISBN 9781491973790

Why shipping features is not the same as delivering outcomes, and what a product operating model looks like. Architects who work with product organizations should know this argument cold.

• BC-510.30Product Roadmapping
• BC-510.40Product Performance Management
• BC-180.60Benefits Realization

Enterprise Architecture as Strategy

Creating a Foundation for Business Execution

Jeanne W. Ross, Peter Weill, David C. Robertson · 2006 · ISBN 9781591398394

Operating model first, then architecture: the diversification, coordination, replication, and unification quadrants still explain why two companies with the same ERP need different integration strategies.

• BC-170.10Architecture Strategy & Principles
• BC-170.20Business Architecture
• BC-710.10Technology Strategy & Operating Model

The Software Architect Elevator

Redefining the Architect's Role in the Digital Enterprise

Gregor Hohpe · 2020 · ISBN 9781492077541

The architect as the person who rides between the executive penthouse and the engine room and carries meaning both ways. Full of reusable metaphors for explaining technical decisions to leadership.

patterns DP-500

• BC-170.10Architecture Strategy & Principles
• BC-170.40Architecture Governance
• BC-710.10Technology Strategy & Operating Model

A Seat at the Table

IT Leadership in the Age of Agility

Mark Schwartz · 2017

An argument from a former government CIO that IT leadership should own business outcomes rather than deliver requirements. Reframes governance, budgeting, and the vendor relationship accordingly.

• BC-710.10Technology Strategy & Operating Model
• BC-710.30IT Policy & Decision Rights
• BC-180.10Investment Prioritization & Funding

Architecture Modernization

Socio-Technical Alignment of Software, Strategy, and Structure

Nick Tune · 2024

Ties domain boundaries, team boundaries, and investment strategy into one modernization approach, with collaborative techniques for discovering the domains instead of assuming them.

patterns DP-210DP-480DP-190

• BC-170.20Business Architecture
• BC-180.40Transformation Program Leadership
• BC-310.30Organization Design

Just Enough Software Architecture

A Risk-Driven Approach

George Fairbanks · 2010 · ISBN 9780984618101

How much architecture work to do is a function of risk, not of process. The right antidote for both no-design agile and heavyweight documentation programs.

patterns DP-500

• BC-170.40Architecture Governance
• BC-720.10Solution Design