Patterns
Patterns
Reusable engineering patterns for distributed systems, observability, and reliability — grounded in production experience at scale.
79 notes
Overview
Patterns
A curated library of reusable engineering patterns drawn from production experience across global observability platforms, AKS clusters, and SRE practice, extended to the full Principal/Staff (L6/L7) pattern landscape. Each pattern is opinionated — it names the context, the forces at play, the solution, and the trade-offs. If this were a book, this page is the table of contents: each Part groups patterns that solve the same class of problem, from pattern thinking itself, through object-oriented design, enterprise architecture, and microservices, out to distributed systems, cloud infrastructure, observability, security, and organizational design. Where a Part overlaps a sibling book already covering the same concept in depth (GoF in
object-oriented-programming/, caching/consensus insystem-design/, K8s multi-container patterns inkubernetes/), that Part’s chapters link out to it rather than duplicate it.
Purpose
This directory holds design patterns structured for repeated application and quick recall. Unlike one-off system designs, these are building blocks: pull out a pattern, adapt it to the target system, and wire it in. The framing keeps observability and reliability as first-class properties of every pattern, not afterthoughts.
The notes are accessible at /notes/patterns/ on the site but are excluded from the main notes
index — they are an internal reference, not public material.
How to Use Each Note
Each pattern follows a consistent structure:
- Context — the situation where this pattern applies
- Problem — the force or constraint being resolved
- Solution — the canonical approach, with a diagram where useful
- Consequences — what you gain, what you give up
- Known uses — where this has been applied in production
Parts
00 — Pattern Thinking
Before the catalog, the vocabulary: what makes something a pattern rather than a one-off decision, how to choose between competing patterns under real forces, and SOLID reframed at architecture scale rather than as a five-bullet mnemonic.
- 01 — What Is a Pattern? — (stub)
- 02 — Pattern Selection & Trade-offs — (stub)
- 03 — SOLID Revisited — Principal-Level Framing — (stub) — see also the per-principle 101-level stubs in Object-Oriented Programming
01 — Object-Oriented Design Patterns (GoF)
The classic Gang of Four catalog, framed as composition and trade-off decisions rather than a 23-pattern memorization exercise. Per-pattern 101-level stubs already live in Object-Oriented Programming; these chapters are the principal-level synthesis layer on top.
- 01 — Creational Patterns — (stub)
- 02 — Structural Patterns — (stub)
- 03 — Behavioral Patterns — (stub)
02 — Enterprise Application Patterns
How a domain model stays coherent and how it talks to everything outside it — layering styles, DDD’s tactical toolkit, transactional integrity, and integration. A genuine gap: no other book in this repo covers Hexagonal/Clean architecture or DDD’s Aggregate/Entity/Repository vocabulary.
- 01 — Layering Patterns — (stub)
- 02 — Domain Modeling Patterns — (stub)
- 03 — Transaction Patterns — (stub) — see also Transactional Outbox
- 04 — Integration Patterns — (stub)
03 — Dependency Injection Patterns
How a dependency graph gets assembled, and how a system stays open to new behavior without recompiling its core.
- 01 — Dependency Management Patterns — (stub)
- 02 — Extensibility Patterns — (stub)
04 — Microservice Patterns
The biggest Part in the book — it absorbs what used to be this book’s entire original 4-Part scaffold (Structural, Communication, Data, Resilience & Operational), regrouped under the outline’s own Service Decomposition / Service Communication / Reliability / Data Patterns chapters. Grouped below with bold sub-headings for scannability; still one Part, matching the outline.
Decomposition — one monolith or many services, and how to migrate between them without a big-bang rewrite.
- 01 — Monolith — Modular and Majestic — a single deployable unit with well-defined internal module boundaries; the right answer when decomposition cost exceeds the benefit
- 02 — Strangler Fig — incrementally replace a legacy system by routing new functionality to a new implementation while the old system keeps running
- 03 — Service Decomposition — (stub) — the remaining decomposition axes: By Business Capability, By Domain, By Bounded Context, Self-Contained Systems
Communication — coordinating work and surviving load without one slow or failed component taking down the request.
- 04 — Fan-Out / Fan-In — decompose a request into parallel sub-tasks, execute concurrently,
merge results; the fullest chapter in this book — nine worked practice questions plus an
observability-KPI companion note
- Fan-Out / Fan-In
- Observability KPIs for the Fan-out / Fan-in Pattern
- Q1 — Search Fan-Out Design
- Q2 — Hedging Trade-off
- Q3 — Context Cancellation Leak
- Q4 — Aggregator Bottleneck
- Q5 — Sizing the Fan-Out Width
- Q6 — Retry Storm
- Q7 — Backpressure and Load Shedding
- Q8 — Hierarchical Fan-Out
- Q9 — Validating Hedging and Deadline Propagation
- 05 — Backpressure — signal from a slow consumer to a fast producer to slow down
- 06 — Service Communication — (stub) — the remaining communication styles: Request-Response, Async Messaging, Event Streaming, Pub/Sub, RPC/gRPC
Reliability — stopping cascading failure, controlling retries, and isolating blast radius.
- 07 — Circuit Breaker — stop calls to a failing dependency before they cascade
- 08 — Retry with Exponential Backoff and Jitter — retry transient failures without a thundering herd
- 09 — Bulkhead — partition resources so one failure can’t exhaust another’s
- 10 — Hedged Requests — send the same request to multiple replicas, use whichever responds first, cancel the rest
- 11 — Reliability Patterns (Microservice Building Blocks) — (stub) — the remaining building blocks: Timeout, Rate Limiter, Fallback, Adaptive Concurrency
Data — keeping data consistent and recoverable once writes and reads happen independently, asynchronously, or across service boundaries.
- 12 — CQRS — Command Query Responsibility Segregation — separate the write model (commands) from the read model (queries)
- 13 — Event Sourcing — store state as an immutable, append-only sequence of domain events
- 14 — Transactional Outbox — atomically write to the database and publish a message
- 15 — Saga — distributed transactions via a sequence of local transactions with compensations
- 16 — Data Patterns (Microservice) — (stub) — the remaining data-ownership patterns: Database-per-Service, Shared Database, Materialized View
05 — Distributed Systems Patterns
Consensus, coordination, replication, and consistency — the primitives underneath every pattern in this book that assumes multiple nodes agree on something.
- 01 — Consensus Patterns — (stub) — see also
system-design/02-distributed-systems-theory/04-consensus-algorithms.mdanddbms’s consensus-in-databases note - 02 — Coordination Patterns — (stub)
- 03 — Replication Patterns — (stub)
- 04 — Consistency Patterns — (stub)
06 — Messaging Patterns
Broker topologies, event patterns, and stream processing semantics — building on Event Sourcing and Saga, already covered in this book.
- 01 — Message Broker Patterns — (stub)
- 02 — Event Patterns — (stub) — see also Event Sourcing and Saga
- 03 — Streaming Patterns — (stub)
07 — API Patterns
REST, RPC, and API Gateway design — the contract layer between a service and everything that calls it.
- 01 — REST Patterns — (stub)
- 02 — RPC Patterns — (stub)
- 03 — API Gateway Patterns — (stub) — see also
system-design/15-complete-case-studies/31-api-gateway/api-gateway.md
08 — Data Patterns (Database, Caching & Search)
Database design, caching, and search — distinct from Part 04’s microservice-scoped Data Patterns chapter (the outline reuses “Data Patterns” as a title twice; disambiguated here).
- 01 — Database Design Patterns — (stub)
- 02 — Caching Patterns — (stub) — see also
system-design/06-caching/01-cache-design-patterns.md - 03 — Search Patterns — (stub)
09 — Cloud Native Patterns
Kubernetes multi-container patterns, deployment strategies, and multi-region availability.
- 01 — Sidecar — co-locate a helper container to handle cross-cutting concerns
- 02 — Kubernetes Patterns — (stub) — the remaining multi-container and
control-plane patterns: Ambassador, Adapter, Init Container, Operator — see also
kubernetes/03-application-design-and-build/multi-container-pod-patterns.mdandplatform-engineering/02-platform-control-plane/crds-and-operators.md - 03 — Cloud Infrastructure Patterns — (stub) — includes Blue-Green/Canary/Rolling deployment strategies
- 04 — Multi-Region Patterns — (stub)
10 — Observability Patterns
Monitoring, logging, tracing, and alerting frameworks — the vocabulary layer above the Observability book’s build-level instrumentation detail, which this Part links to rather than duplicates.
- 01 — Monitoring Patterns — (stub)
- 02 — Logging Patterns — (stub)
- 03 — Tracing Patterns — (stub)
- 04 — Alerting Patterns — (stub) — see also
3-references/Observability/slo/slo-design-patterns.md
11 — Reliability Patterns (Resilience, Availability & Scale)
System-level resilience postures, availability practices, and scaling levers — one level above any single pattern like Circuit Breaker or Bulkhead. Named “Resilience, Availability & Scale” rather than “Reliability Patterns” to avoid colliding with Part 04’s chapter of the same outline title.
- 01 — Resilience Patterns — (stub)
- 02 — Availability Patterns — (stub) — see also
4-archive/g-reliability/chaos/and thedr-runbook-writerskill - 03 — Scalability Patterns — (stub)
12 — Security Patterns
Authentication, authorization, and secure communication — a genuine gap; b-security/ is
charter-only with no content yet.
- 01 — Authentication Patterns — (stub)
- 02 — Authorization Patterns — (stub)
- 03 — Secure Communication Patterns — (stub)
13 — Concurrency Patterns
Threading, lock-free programming, and async composition — the concurrency primitives underneath patterns like Fan-Out/Fan-In and Backpressure.
- 01 — Threading Patterns — (stub)
- 02 — Lock-Free Programming — (stub)
- 03 — Async Patterns — (stub)
14 — AI & Agentic System Patterns
The pattern vocabulary for composing LLM calls into a system — a synthesis layer above Agentic AI Engineering‘s and Building & Evaluating Agents’ build-level RAG and multi-agent content, which this Part links to rather than rebuilds.
- 01 — LLM System Patterns — (stub) — see also
agentic-ai-engineering/02-memory-systems/,agentic-ai-engineering/05-retrieval-and-knowledge-systems/, andbuilding-agentic-systems/01-multi-agent-systems/ - 02 — AI Infrastructure Patterns — (stub)
15 — Organizational Patterns
Team Topologies, Conway’s Law, and the governance scaffolding that lets an organization make architecture decisions without every one becoming a meeting.
- 01 — Team Topologies —
(stub) — see also
observability/07-org-and-narrative/building-a-platform-team.md - 02 — Conway’s Law — (stub)
- 03 — Engineering Leadership Patterns — (stub) — see also the
adr-writerskill anda-governance/’s ADR process
16 — Architecture Decision Patterns
Recurring architecture forks and the trade-off frameworks that actually resolve them.
- 01 — Decision-Making Patterns — (stub) — see also Monolith and Strangler Fig
- 02 — Trade-off Analysis Frameworks — (stub)
17 — Pattern Composition
How patterns interact once more than one is applied to the same system, the failure modes that look like patterns but aren’t, and case studies of how real companies combined them in production.
- 01 — Combining Patterns — (stub)
- 02 — Anti-Patterns — (stub)
- 03 — Pattern Case Studies — (stub) — one chapter covering Amazon/Google/Netflix/Uber/Stripe/LinkedIn/Cloudflare; splits into per-company notes once one is actually researched and written
Deferred: the outline’s Appendix (cross-cutting matrices and cheat sheets) isn’t stubbed here — it’s a reference index over content that doesn’t exist yet. Worth a follow-up pass once enough of the chapters above are actually written to make the matrices meaningful.
Shared Concepts
Some ideas support more than one pattern — or a full system design — without being a pattern
themselves. Those live inside observability/‘s book-chapter structure
instead of nested under whichever pattern first needed them, and get pulled in via [[wikilink]]
from wherever they’re relevant:
- 8 — Deadline Propagation — a client deadline must be inherited by every downstream call
- 5 — Partial Results vs Fail-Fast — fail-fast vs. best-effort vs. quorum when part of a fan-out fails
- 2 — Shards vs Workers — the distinction between a data partition and an execution unit
- 9 — Fan-Out Metrics and Trace Shape — how a scatter-gather call tree should look in a distributed trace
- 8 — Query Sharding — splitting one query’s computation across N workers, distinct from partitioning where the data lives
See observability/README.md for the full book structure, including concepts shared with the design library.
Metadata
| Dimension | Detail |
|---|---|
| Author | Amit Singh |
| Scope | Engineering reference — not production documentation |
| Access | Internal — hidden from public notes index via HIDDEN_TOPICS in src/pages/notes/index.astro |
| Landing page | src/pages/notes/patterns/index.astro → /notes/patterns/ |