Architecture Patterns Catalog
Curated reference of proven patterns with guidance on when and how to apply them.
Context
You are designing a system and want to know proven patterns that solve your problem. Reference catalog of patterns: when to use, tradeoffs, real-world examples.
Domain Context
Based on pattern catalogs (Gang of Four, Enterprise Patterns, Domain-Driven Design):
- Structural Patterns: How components fit together (Adapter, Facade, Bridge)
- Behavioral Patterns: How components interact (Observer, Strategy, State)
- Architectural Patterns: System-level patterns (Microservices, Event-Driven, CQRS)
- Data Patterns: How data flows (ETL, CDC, Event Sourcing)
- Messaging Patterns: How services communicate (Request-Reply, Pub-Sub, Saga)
Pattern Categories with Examples
-
Communication Patterns:
- Synchronous (Request-Reply): REST, gRPC. Blocking, tight coupling, simple.
- Asynchronous (Pub-Sub): Message broker, events. Loose coupling, eventual consistency.
- Saga Pattern: Distributed transaction across services. Orchestrator vs choreographer.
-
Data Patterns:
- Event Sourcing: Store events as source of truth. Auditability, temporal queries, replay.
- CQRS: Separate read and write models. Scalability, complexity.
- Polyglot Persistence: Different databases for different workloads. Flexibility, operational complexity.
-
Resilience Patterns:
- Circuit Breaker: Stop calling failing service, fast-fail. Prevent cascade failure.
- Bulkhead: Isolate resources (threads, connections). One service failure doesn't starve others.
- Retry with Backoff: Retry with exponential backoff. Transient failures recover.
-
Scalability Patterns:
- Sharding: Partition data across databases. Horizontal scaling, complexity.
- Caching: Cache hot data. Latency, consistency trade-off.
- Load Balancing: Distribute across instances. Horizontal scaling.
Instructions
-
Identify Problem: What are you trying to solve? Scaling? Reliability? Loose coupling?
-
Search Catalog: What patterns address this problem?
-
Evaluate Trade-offs: Benefits vs complexity? Team capability? Do we have the infrastructure?
-
Choose Pattern(s): Often combine patterns. Saga + Circuit Breaker. Sharding + Replication.
-
Implement Carefully: Patterns solve some problems, create others. Monitor carefully.
-
Document: Why you chose this pattern. What trade-offs accepted. What could go wrong.
Anti-Patterns in Pattern Use
- Pattern Memorization Without Understanding: Apply pattern because it's trendy. Result: wrong for problem. Guard: Understand pattern's purpose; ensure problem matches.
- Overusing One Pattern: Everything is microservices or event-driven. Result: wrong tool for job. Guard: Different problems, different patterns.
- Incomplete Implementation: Use circuit breaker but not monitoring. Result: fails silently. Guard: Implement full pattern; test failure scenarios.
- No Evolution Path: Choose pattern, stuck with it forever. Result: outdated, painful. Guard: Design to evolve; refactor when costs exceed benefits.
Further Reading
- Design Patterns: Elements of Reusable Object-Oriented Software by Gang of Four — foundational patterns
- Enterprise Integration Patterns by Gregor Hohpe — messaging and integration patterns
- Building Microservices by Sam Newman — microservice patterns
- Patterns of Enterprise Application Architecture by Martin Fowler — application architecture patterns