Design Patterns MOC
Design Patterns MOC
Root entry point for the Software Engineering Patterns vault. Covers 109 notes across thirteen domains: Gang of Four (GoF), Domain-Driven Design (DDD), Enterprise Integration Patterns (EIP), CQRS and Event Sourcing, Saga, Microservices Deployment, Cloud-Native Release, Application Architecture, API Design, System Design, Security, Observability, Algorithms, and Frontend Architecture. From here, any note is reachable in two hops: root MOC -> category MOC -> atomic note.
Pattern Categories
- GoF-Patterns-MOC — 23 Gang of Four patterns: creational, structural, behavioral
- Enterprise-Patterns-MOC — DDD, EIP, CQRS/Event Sourcing, Saga patterns
- Deployment-Patterns-MOC — Microservices infrastructure and cloud-native release patterns
- Application-Architecture-MOC — 6 application architecture patterns: layered family (Clean, Hexagonal, Onion) and orthogonal architectures (Vertical Slice, Modular Monolith, Micro-Frontends)
- API-Protocol-Selection-MOC -- REST, GraphQL, gRPC, and WebSocket protocol selection with decision flowchart and comparison table
- System-Design-MOC — 19 system design notes: 11 building blocks (foundation + infrastructure) and 8 case studies (simple + scale-heavy)
- Security-MOC — 10 security pattern notes: authentication (OAuth2, JWT, sessions, API keys), authorization (RBAC/ABAC), transport and secrets (encryption, secrets management), browser boundary (CORS/CSP, input validation), and architecture posture (Zero Trust)
- Observability-MOC — 9 observability pattern notes: three pillars (structured logging, metrics/dashboards, distributed tracing patterns) and reliability engineering (SLO/SLI/SLA, alerting, runbooks, incident response, on-call, post-mortems)
- Algorithms-MOC — Algorithm-to-architecture cross-domain index: system design application mapping, cross-domain lineage chains, and three algorithm concept notes (HyperLogLog, Geohash, Merkle Tree)
- Frontend-Architecture-MOC — 6 frontend architecture pattern notes: state management (Flux/Redux, Signals, Atomic, Observable/RxJS), rendering strategies (SSG/ISR/SSR/CSR/PPR), hydration patterns, change detection and rendering engines, component composition patterns, and atomic design
Cross-Layer Lineage Chains
Patterns evolve across layers. Each chain traces an idea from its GoF origin to its enterprise or deployment descendant.
Learner Path
Follow this dependency-ordered sequence to build vocabulary before tackling enterprise and deployment patterns.
-
Stage 1: GoF Vocabulary — Start with GoF-Patterns-MOC. Work through Creational (Factory-Method-Pattern, Builder-Pattern, Prototype-Pattern), then Structural (Adapter-Pattern, Decorator-Pattern, Proxy-Pattern, Facade-Pattern), then Behavioral (Strategy-Pattern, Observer-Pattern, Command-Pattern, State-Pattern). These 23 patterns are the vocabulary all later patterns assume.
-
Stage 2: DDD Tactical — Move to Enterprise-Patterns-MOC for DDD patterns: Value-Object, Aggregate, Repository, Domain-Events, Bounded-Context, Anti-Corruption-Layer-Pattern. DDD tactical patterns are prerequisites for understanding CQRS projections and Saga event flow.
-
Stage 3: Integration — Continue with EIP patterns in Enterprise-Patterns-MOC: Pipes-and-Filters, Message-Router, Aggregator, Splitter, Dead-Letter-Queue, Idempotent-Consumer. These underpin saga compensation and event-driven microservices.
-
Stage 4: CQRS/ES — Study CQRS and Event Sourcing in Enterprise-Patterns-MOC: CQS-Principle, CQRS-Pattern, Event-Sourcing-Pattern, Projections. CQRS/ES sits above DDD and EIP in the dependency graph.
-
Stage 5: Sagas — Complete the enterprise layer with Saga patterns in Enterprise-Patterns-MOC: Choreography-Saga-Pattern, Orchestration-Saga-Pattern, Compensating-Transactions.
-
Stage 6: Deployment — Move to Deployment-Patterns-MOC for microservices infrastructure: Circuit-Breaker-Pattern, API-Gateway-Pattern, Sidecar-Pattern, Ambassador-Pattern, Service-Mesh-Pattern, Strangler-Fig-Pattern.
-
Stage 7: Release — Finish with cloud-native release patterns in Deployment-Patterns-MOC: Feature-Flags-Pattern, Canary-Release-Pattern, Blue-Green-Deployment, Rolling-Deployment, 12-Factor-App.
-
Stage 8: Application Architecture — Move to Application-Architecture-MOC for the structural shells that organise individual design patterns: Clean-Architecture, Hexagonal-Architecture, Onion-Architecture, Vertical-Slice-Architecture, Modular-Monolith, Micro-Frontends.
-
Stage 9: API Design -- Complete the vocabulary with API-Protocol-Selection-MOC for protocol selection. Study REST-API-Design first (the default protocol); then Operational-API-Patterns (cross-protocol operational contracts -- pagination, idempotency, rate limiting); then GraphQL-API-Design (field selection, N+1/DataLoader, federation); then gRPC-Service-Design (contract-first RPC, streaming types, interceptors). Use the API-Protocol-Selection-MOC decision flowchart to select the right protocol for a given integration.
-
Stage 10: System Design — Move to System-Design-MOC for distributed systems primitives. Start with Capacity-Estimation (prerequisite math for all designs); then Foundation Building Blocks (CAP-Theorem, Consistent-Hashing, Bloom-Filter); then Infrastructure Building Blocks (Load-Balancer, Distributed-Cache, Content-Delivery-Network, Message-Queue, SQL-vs-NoSQL, Database-Replication, Database-Sharding). Apply building blocks to Case Studies: Simple (URL-Shortener-Design, Rate-Limiter-Design, Unique-ID-Generator-Design, Notification-System-Design), then Scale-Heavy (News-Feed-Design, Chat-System-Design, Search-Autocomplete-Design, Web-Crawler-Design).
-
Stage 11: Security and Observability — Complete the operational vocabulary with Security-MOC and Observability-MOC. Start with security foundations: OAuth2-OIDC-Flows (grant type taxonomy), JWT (token validation), RBAC-ABAC (authorization model), Session-Management (session lifecycle). Then security infrastructure: Secrets-Management, Encryption, Zero-Trust-Architecture, CORS-CSP, Input-Validation, API-Key-Authentication. Then observability three pillars: Structured-Logging, Metrics-and-Dashboards, Distributed-Tracing-Patterns. Finish with reliability engineering: SLO-SLI-SLA (prerequisite for alerting), Alerting-Strategies, Runbook-Design, Incident-Response, On-Call-Practices, Post-Mortem. Security and observability are cross-cutting concerns that apply to every pattern domain studied in Stages 1-10.
-
Stage 12: Frontend Architecture — Move to Frontend-Architecture-MOC for intra-application frontend patterns. Start with State-Management-Patterns (choose among Flux/Redux, Signals, Atomic stores, and Observable/RxJS using explicit suitability thresholds for both React and Angular ecosystems); then Rendering-Strategies and Hydration-Patterns (server-to-client rendering spectrum and hydration strategy selection); then Change-Detection-and-Rendering-Engines (how React Virtual DOM, Angular zone.js/OnPush/Signals, and Solid fine-grained reactivity each solve the DOM update problem); then component patterns Component-Composition-Patterns and Atomic-Design-Pattern (HOC, hooks, directives, inject functions, and design system composition — each with explicit GoF lineage). Frontend Architecture assumes Stage 8 (Application-Architecture-MOC) for understanding the macro-level shell (Micro-Frontends) in which these patterns operate.
Reference Path: Symptom Guide
Already know what problem you're facing? Find the pattern.
| Symptom / Problem | Pattern(s) |
|---|---|
| Need multiple notification targets, decoupled from sender | Observer-Pattern |
| Need audit trail or temporal queries | Event-Sourcing-Pattern |
| Reads vastly outscale writes (~10x) | CQRS-Pattern |
| Distributed transaction across 3+ services | Choreography-Saga-Pattern or Orchestration-Saga-Pattern |
| Integrating incompatible legacy interface | Adapter-Pattern or Anti-Corruption-Layer-Pattern |
| Need to add behaviour without modifying class | Decorator-Pattern |
| Cascading failures between services | Circuit-Breaker-Pattern |
| Legacy modernisation too risky for big-bang | Strangler-Fig-Pattern |
| Runtime algorithm swap | Strategy-Pattern |
| Complex object construction (4+ params) | Builder-Pattern |
| Message loss is unacceptable | Dead-Letter-Queue |
| Duplicate message processing | Idempotent-Consumer |
| Safe traffic routing to new version | Canary-Release-Pattern or Blue-Green-Deployment |
| Cross-cutting concerns in microservices | Sidecar-Pattern or Service-Mesh-Pattern |
| Single expensive object creation | Singleton-Pattern (with DI caveat — see note) |
| Simplify complex subsystem interface | Facade-Pattern |
| Feature teams stepping on each other's code | Vertical-Slice-Architecture |
| Need deployment independence without microservices overhead | Modular-Monolith |
| 3+ frontend teams with independent releases | Micro-Frontends |
| Confused about Clean vs Hexagonal vs Onion | Application-Architecture-MOC (selection guide) |
| Public API for unknown or third-party clients | REST-API-Design |
| Clients need to fetch deeply nested or graph-shaped data with field selection | GraphQL-API-Design |
| Internal service-to-service communication with streaming or binary performance requirements | gRPC-Service-Design |
| Non-idempotent POST/payment operation that must be safe to retry | Operational-API-Patterns (idempotency keys) |
| Large list endpoint returning too much data or causing timeouts | Operational-API-Patterns (cursor pagination) |
| Service-to-service N+1 fanout is performance bottleneck | GraphQL-API-Design (DataLoader) or gRPC-Service-Design |
| Need to estimate server/storage requirements before design | Capacity-Estimation |
| Distributed system: partition vs consistency tradeoff | CAP-Theorem |
| Hot-shard or uneven load across database nodes | Consistent-Hashing or Database-Sharding |
| Cache penetration or membership check at scale | Bloom-Filter |
| Traffic spike — need to distribute requests | Load-Balancer |
| Database read latency too high | Distributed-Cache or Database-Replication |
| Static asset delivery to global users | Content-Delivery-Network |
| Service-to-service decoupling, async processing | Message-Queue |
| Choosing database model for a new system | SQL-vs-NoSQL |
| Need globally unique IDs without coordination | Unique-ID-Generator-Design |
| Short URL with analytics and redirect | URL-Shortener-Design |
| Per-user or per-API rate limiting at scale | Rate-Limiter-Design |
| Reliable cross-channel notification delivery | Notification-System-Design |
| Social feed with celebrity accounts (10M+ followers) | News-Feed-Design |
| Real-time messaging with offline delivery | Chat-System-Design |
| Autocomplete suggestions under 100ms | Search-Autocomplete-Design |
| Distributed web crawling without duplication | Web-Crawler-Design |
| Need delegated authorization for user-facing client (SPA, mobile) | OAuth2-OIDC-Flows (Authorization Code + PKCE) |
| Service-to-service authentication without OAuth2 infrastructure | API-Key-Authentication (dual-active rotation) |
| Validating JWT tokens between services | JWT (signature before claims, algorithm selection) |
| Choosing role-based vs attribute-based authorization | RBAC-ABAC (start RBAC, add ABAC policies as needed) |
| Server-side session with instant revocation capability | Session-Management (Redis-backed httpOnly cookie) |
| Rotating database credentials without downtime | Secrets-Management (dual-credential rotation) |
| Choosing encryption approach by data state (rest/transit/use) | Encryption (AES-256-GCM, TLS 1.3, envelope DEK+KEK) |
| Eliminating implicit trust from network position | Zero-Trust-Architecture (identity + policy + network planes) |
| Browser cross-origin request control or script loading policy | CORS-CSP (CORS allowlist + CSP nonce/hash) |
| Blocking malicious input before business logic | Input-Validation (allowlist schema validation at trust boundary) |
| Need structured JSON logging with trace correlation | Structured-Logging (mandatory field schema, MDC propagation) |
| Choosing measurement framework (RED vs USE vs Golden Signals) | Metrics-and-Dashboards (RED for request-driven, USE for infra) |
| Debugging cross-service latency, choosing sampling strategy | Distributed-Tracing-Patterns (head-based, tail-based, probabilistic) |
| Defining reliability targets and error budgets | SLO-SLI-SLA (SLI ratio, burn rate, multiwindow alerting) |
| Configuring alerts that fire on user impact, not internal causes | Alerting-Strategies (symptom-based, multi-window multi-burn-rate) |
| Creating operational documentation for on-call engineers | Runbook-Design (context, diagnostics, remediation, escalation) |
| Handling production incidents with clear roles | Incident-Response (commander coordinates, experts fix) |
| Sustainable on-call rotation and toil measurement | On-Call-Practices (toil < 50%, MTTA < 5min P1) |
| Learning from incidents without blame | Post-Mortem (5-whys, counterfactual test, Prevention/Detection/Mitigation) |
| Frontend state shared across 3+ features, prop drilling pain | State-Management-Patterns (Flux/Redux: RTK for React, NgRx for Angular) |
Angular app with too many ChangeDetectionStrategy.Default re-renders | State-Management-Patterns (Angular Signals) or Change-Detection-and-Rendering-Engines (OnPush strategy) |
| Need SSR for SEO but app has dynamic per-user data | Rendering-Strategies (SSR) or Rendering-Strategies (PPR/Streaming) |
| Large Next.js or Angular page slow to become interactive (high TTI) | Hydration-Patterns (partial or islands hydration) |
| Angular zone.js causing excessive change detection cycles | Change-Detection-and-Rendering-Engines (OnPush + zoneless Signals) |
| React component re-renders too often despite unchanged props | Change-Detection-and-Rendering-Engines (Virtual DOM reconciliation, key-based) |
| Component has too many responsibilities, hard to test in isolation | Component-Composition-Patterns (HOC/hook extraction in React; directive/inject in Angular) |
| Need to build a reusable component library or design system | Atomic-Design-Pattern |
| Confused about HOC vs hooks vs render props | Component-Composition-Patterns (selection guide) |
| Need to count distinct elements at scale (billions, ~1% error OK) | HyperLogLog (Redis PFADD/PFCOUNT; 12 KB fixed memory) |
| Need location-based proximity search or geographic data sharding | Geohash (binary space partitioning; prefix = shard key) |
| Need to detect data divergence between replicas efficiently | Merkle-Tree (O(log n) anti-entropy repair; Cassandra/DynamoDB) |
Sources
Pattern catalogue based on GoF (1994), Hohpe/Woolf EIP (2003), Evans DDD (2003), Vernon IDDD (2013), Richardson Microservices Patterns (2018), Newman Building Microservices (2021). Kleppmann Designing Data-Intensive Applications (2017), Xu System Design Interview Vol. 1 (2020). NIST SP 800-207 — Zero Trust Architecture. RFC 6749 — OAuth 2.0. RFC 7519 — JWT. OWASP Top 10 (2021). Google SRE Book (2016). Google SRE Workbook (2018). Majors, Fong-Jones, Miranda — Observability Engineering (2022).