„Old“ pattern books like the Gang of Four patterns and the Pattern Oriented Software Architecture patterns were published 30 years ago. Since that time new technologies emerged and new experiences with software engineering were collected. There are a lot of unchartered territories for which new patterns have been identified, but not always documented. This article reworks some of the classical patterns. It adds new architecture and design patterns that may be interesting to document using one of the pattern templates (for example, GoF or POSA style).
Hint: I wrote the original version of this article using format, but left some parts in their Markdown format. Some would define it as laziness. And they are right.
Refined Classical Patterns
Bounded Singleton
**Context:**
Traditional singletons enforce a strict limit of one instance, but many systems benefit from a controlled number of instances while maintaining the core benefits of instance control.
**Problem:**
The classic Singleton pattern is too restrictive for scenarios requiring limited concurrency, load balancing, or fault tolerance. However, unrestricted instantiation leads to resource contention and inconsistent state.
**Solution:**
The Bounded Singleton pattern extends the traditional Singleton by allowing a configurable, fixed number of instances. It maintains a registry of active instances, manages their lifecycle, and provides instance selection strategies for clients.
**Participants:**
- **Instance Registry**: Tracks and limits the number of instances
- **Instance Factory**: Creates and initializes new instances when permitted
- **Selection Strategy**: Determines which instance to provide to clients
- **Instance Monitor**: Tracks health and usage of instances
**Consequences:**
- **Positive**: Enables controlled concurrency while preventing proliferation
- **Positive**: Supports load balancing across limited instances
- **Positive**: Facilitates resource pooling with upper bounds
- **Negative**: More complex implementation than traditional Singleton
- **Negative**: Potential bottlenecks at the registry level
**Known Uses:**
- Database connection pools with maximum connection limits
- Thread-safe object pools in high-performance systems
- License-constrained service managers
Event Sourcing+
**Context:**
Long-lived systems that rely on event sourcing face challenges when domain models evolve over time. Traditional event sourcing captures state changes as immutable events but struggles with schema evolution.
**Problem:**
As systems mature, the structure of events inevitably changes. New fields are added, semantics shift, and relationships between entities evolve. Without a mechanism to handle this evolution, systems become brittle and difficult to maintain, often requiring complex migration scripts or maintaining multiple versions of event handlers.
**Solution:**
Event Sourcing+ extends traditional event sourcing by incorporating versioning and schema evolution directly into the event model. Events are stored with rich metadata including schema version, transformation rules, and semantic context. The system maintains transformation functions that can convert events between versions, allowing older events to be interpreted correctly by newer code.
**Participants:**
- **Event Store**: Persists events with version metadata
- **Schema Registry**: Maintains event schemas across versions
- **Event Transformer**: Contains rules to transform events between schema versions
- **Event Processor**: Applies appropriate transformations before processing events
**Consequences:**
- **Positive**: Systems can evolve without expensive migrations
- **Positive**: Historical data remains accessible and meaningful
- **Positive**: Reduces technical debt from schema drift
- **Negative**: Increased complexity in event processing pipeline
- **Negative**: Performance overhead from transformation operations
**Known Uses:**
- Financial systems with decade-long audit requirements
- Healthcare record systems that evolve with regulatory changes
- E-commerce platforms that maintain order history across major platform revisions
Composite Microservice
**Context:**
Microservice architectures often grow organically, leading to complex interaction patterns and dependencies that become difficult to manage and understand.
**Problem:**
Direct point-to-point communication between many microservices creates a tangled web of dependencies. Client applications must understand complex orchestration logic, and changes to service interactions require updates across multiple services.
**Solution:**
The Composite Microservice pattern creates a hierarchy where microservices can be atomic or composite. Composite services orchestrate other services while presenting a unified interface to clients. This creates a tree-like structure that simplifies complex operations while maintaining the microservice philosophy.
**Participants:**
- **Atomic Service**: Performs a single business capability
- **Composite Service**: Orchestrates multiple services while maintaining the same contract style
- **Service Registry**: Tracks available services and their capabilities
- **Client**: Interacts with either atomic or composite services without needing to know the difference
**Consequences:**
- **Positive**: Reduces client complexity by abstracting orchestration
- **Positive**: Enables incremental refactoring of service boundaries
- **Positive**: Improves system comprehensibility through hierarchical organization
- **Negative**: Can introduce additional network hops
- **Negative**: Risk of creating monolithic services if overused
**Known Uses:**
- E-commerce order processing pipelines
- Financial transaction processing systems
- Travel booking platforms that coordinate multiple reservation systems
Reactive Observer
**Context:**
Modern distributed systems process high volumes of events across services with varying processing capabilities and reliability characteristics.
**Problem:**
Traditional observer patterns can lead to message flooding, where fast producers overwhelm slow consumers. Additionally, when observers fail, the entire notification chain can be disrupted.
**Solution:**
Reactive Observer extends the observer pattern with backpressure handling and failure isolation mechanisms. Observers signal their processing capacity to subjects, and the pattern incorporates circuit-breaking to isolate failing observers.
**Participants:**
- **Subject**: Maintains observer registry and respects backpressure signals
- **Observer**: Processes notifications and signals processing capacity
- **Backpressure Controller**: Manages flow control between subjects and observers
- **Circuit Breaker**: Monitors observer health and temporarily removes failing observers
**Consequences:**
- **Positive**: Prevents system overload during traffic spikes
- **Positive**: Improves system resilience through failure isolation
- **Positive**: Enables self-healing notification chains
- **Negative**: Increased complexity in notification logic
- **Negative**: Potential for reduced throughput due to conservative backpressure
**Known Uses:**
- Real-time analytics processing pipelines
- IoT sensor data collection systems
- Financial market data distribution networks
Cloud-Native Patterns
Containerization Pattern Family
Container Boundary
**Context:**
Modern applications are increasingly deployed as containers, requiring clear principles for determining container boundaries and responsibilities.
**Problem:**
Without clear guidelines for containerization, teams often create containers that are either too granular (increasing orchestration complexity) or too coarse (losing isolation benefits). Inappropriate container boundaries lead to deployment inefficiencies and operational challenges.
**Solution:**
The Container Boundary pattern provides principles for defining optimal container boundaries based on deployment lifecycle, scaling characteristics, and resource profiles. It establishes guidelines for what should be included in a single container versus split across multiple containers.
**Participants:**
- **Primary Process**: The main application process that defines the container's purpose
- **Sidecar Processes**: Optional helper processes that support the primary process
- **Resource Definition**: Explicit declaration of container resource requirements
- **Lifecycle Hooks**: Entry points for container lifecycle management
**Consequences:**
- **Positive**: Optimized resource utilization through appropriate container sizing
- **Positive**: Simplified deployment and scaling operations
- **Positive**: Clear separation of concerns between containers
- **Negative**: Requires careful analysis of application characteristics
- **Negative**: May necessitate application refactoring to align with container boundaries
**Known Uses:**
- Microservice architectures deployed on Kubernetes
- Cloud-native application modernization projects
- DevOps pipeline containerization
Immutable Container
**Context:**
Container-based deployments benefit from immutability to ensure consistency across environments and simplify operations.
**Problem:**
Modifying running containers creates snowflake instances that drift from their original configuration, leading to environment inconsistencies, troubleshooting difficulties, and deployment unpredictability.
**Solution:**
The Immutable Container pattern enforces that containers never change after deployment. Configuration changes, updates, or fixes require building new container images and redeploying. Runtime state is externalized to dedicated stateful services.
**Participants:**
- **Container Image**: Immutable blueprint defining the container
- **Configuration Injection**: External mechanism for providing configuration
- **State Store**: External system for maintaining persistent state
- **Deployment Orchestrator**: System that replaces containers rather than modifying them
**Consequences:**
- **Positive**: Consistent behavior across all environments
- **Positive**: Simplified rollback through image versioning
- **Positive**: Improved security through reduced attack surface
- **Negative**: Requires robust CI/CD for frequent rebuilds
- **Negative**: Necessitates external state management
**Known Uses:**
- Production Kubernetes deployments
- Serverless container platforms
- Highly regulated environments requiring deployment validation
Kubernetes Operator
**Context:**
Complex applications on Kubernetes require domain-specific knowledge for proper deployment, scaling, and management that goes beyond generic orchestration.
**Problem:**
Standard Kubernetes resources lack domain-specific knowledge about application lifecycle, scaling patterns, and recovery procedures, leading to manual operational overhead and inconsistent management.
**Solution:**
The Kubernetes Operator pattern extends Kubernetes with custom controllers that encode domain-specific operational knowledge. Operators watch for custom resource changes and execute complex workflows to achieve the desired state, automating domain-specific operations.
**Participants:**
- **Custom Resource Definition**: Extends Kubernetes API with application-specific resources
- **Controller**: Watches custom resources and executes reconciliation logic
- **Reconciliation Loop**: Continuously works to achieve and maintain desired state
- **Status Reporter**: Updates resource status to reflect current state
**Consequences:**
- **Positive**: Automates complex application-specific operations
- **Positive**: Encapsulates operational expertise in code
- **Positive**: Enables self-healing at the application level
- **Negative**: Requires significant development investment
- **Negative**: Increases complexity of the Kubernetes cluster
**Known Uses:**
- Database deployments on Kubernetes (e.g., PostgreSQL, MongoDB)
- Message broker management (e.g., Kafka, RabbitMQ)
- Complex stateful applications with specific scaling requirements
Sidecar Configuration
**Context:**
Modern cloud applications require dynamic configuration management that can adapt to changing environments without application restarts.
**Problem:**
Embedding configuration management directly into applications creates tight coupling between business logic and infrastructure concerns. This makes applications less portable and complicates configuration updates.
**Solution:**
The Sidecar Configuration pattern externalizes configuration management to a dedicated sidecar container or process. The main application remains configuration-agnostic, interacting with a simple local API to retrieve settings. The sidecar handles dynamic updates, validation, and distribution.
**Participants:**
- **Main Application**: Focuses on business logic, retrieves configuration through local API
- **Configuration Sidecar**: Manages configuration lifecycle, including updates and validation
- **Configuration Source**: External system providing configuration values (e.g., etcd, Consul)
- **Configuration API**: Local interface between main application and sidecar
**Consequences:**
- **Positive**: Separation of concerns between business logic and configuration management
- **Positive**: Enables zero-downtime configuration updates
- **Positive**: Simplifies application code by externalizing configuration complexity
- **Negative**: Additional deployment complexity
- **Negative**: Potential single point of failure if not properly designed
**Known Uses:**
- Kubernetes-based applications using ConfigMaps
- Service mesh implementations like Istio
- Cloud-native databases with dynamic configuration requirements
Boundary Polyglot
**Context:**
Modern systems often benefit from using different programming languages for different components, leveraging language-specific strengths.
**Problem:**
Mixing languages in a system introduces complexity in communication, deployment, and maintenance. Without clear boundaries, polyglot systems can become chaotic and difficult to evolve.
**Solution:**
The Boundary Polyglot pattern formalizes how to design language transition points at domain boundaries with well-defined contracts. It specifies serialization formats, error handling approaches, and deployment strategies that minimize translation overhead.
**Participants:**
- **Domain Boundary**: Well-defined interface where language transition occurs
- **Contract Definition**: Language-neutral specification of the interface
- **Serialization Layer**: Handles data translation between language-specific formats
- **Error Mapping**: Translates exceptions and errors between language paradigms
**Consequences:**
- **Positive**: Enables using the best language for each component
- **Positive**: Creates clear boundaries that improve system modularity
- **Positive**: Facilitates incremental language migration
- **Negative**: Increased complexity in build and deployment pipelines
- **Negative**: Potential performance overhead from serialization/deserialization
**Known Uses:**
- Systems with performance-critical components in languages like Rust alongside business logic in higher-level languages
- Data processing systems using Python for analytics with Java for infrastructure
- Web applications with JavaScript frontends and statically-typed backend languages
Resilient State Transfer
**Context:**
Distributed systems must maintain data consistency across service boundaries despite network failures, partial outages, and varying load conditions.
**Problem:**
Traditional request-response patterns are vulnerable to network partitions and service failures, leading to inconsistent state across services or blocked operations.
**Solution:**
Resilient State Transfer implements a combination of optimistic updates, conflict resolution, and eventual consistency guarantees. Services maintain local state that can diverge temporarily but will eventually converge through background reconciliation processes.
**Participants:**
- **State Owner**: Service that has primary authority over a piece of state
- **State Consumer**: Service that maintains a local copy of state
- **Change Log**: Append-only record of state modifications
- **Reconciliation Engine**: Background process that resolves conflicts and ensures consistency
**Consequences:**
- **Positive**: Operations can continue during partial system outages
- **Positive**: Improved responsiveness by avoiding synchronous dependencies
- **Positive**: Natural audit trail through the change log
- **Negative**: Increased complexity in conflict resolution
- **Negative**: Temporary inconsistency between services
**Known Uses:**
- Multi-region database systems
- Collaborative editing applications
- Inventory management across distributed warehouses
AI and LLM Application Patterns
Prompt Chain Responsibility
**Context:**
Complex AI tasks often require multiple steps of reasoning or processing that exceed the capabilities of a single prompt-response interaction.
**Problem:**
Attempting to solve complex problems with a single prompt often leads to incomplete reasoning, hallucinations, or responses that miss critical aspects of the problem.
**Solution:**
Prompt Chain Responsibility organizes LLM interactions as a chain of specialized prompts, each handling a specific aspect of a complex task. Each prompt in the chain has clear responsibilities and passes its output to the next prompt, enabling complex reasoning through decomposition.
**Participants:**
- **Chain Coordinator**: Manages the flow between prompts and aggregates results
- **Specialized Prompts**: Individual prompts with focused responsibilities
- **Context Manager**: Ensures relevant information is passed between chain links
- **Output Validator**: Verifies each step meets quality criteria before proceeding
**Consequences:**
- **Positive**: Enables complex multi-step reasoning
- **Positive**: Improves reliability through focused, verifiable steps
- **Positive**: Creates traceable reasoning paths
- **Negative**: Increased token usage and API costs
- **Negative**: Higher latency due to multiple LLM calls
**Known Uses:**
- Complex legal document analysis
- Multi-step mathematical problem solving
- Research synthesis applications
Context Window Management
**Context:**
LLMs have finite context windows that limit the amount of information they can process in a single interaction, creating challenges for applications dealing with large documents or extended conversations.
**Problem:**
When information exceeds the context window, LLMs lose access to potentially critical details, leading to incomplete or incorrect responses. Simply truncating content often removes important context.
**Solution:**
The Context Window Management pattern defines strategies for information prioritization, summarization, and retrieval. It implements techniques like sliding windows, hierarchical summarization, and semantic chunking to maintain coherence across large datasets or conversations.
**Participants:**
- **Content Chunker**: Divides large content into semantically meaningful segments
- **Priority Manager**: Determines which chunks should remain in context
- **Summary Generator**: Creates condensed representations of out-of-window content
- **Context Assembler**: Constructs the optimal context window for each interaction
**Consequences:**
- **Positive**: Enables working with documents larger than the context window
- **Positive**: Maintains conversation coherence over extended interactions
- **Positive**: Optimizes token usage by prioritizing relevant content
- **Negative**: Potential information loss through summarization
- **Negative**: Computational overhead from content management
**Known Uses:**
- Document analysis systems processing large legal or technical documents
- Long-running customer support chatbots
- Research assistants working with multiple academic papers
Hallucination Guard
**Context:**
LLMs can generate plausible-sounding but factually incorrect information, creating risks for applications where accuracy is critical.
**Problem:**
Hallucinations undermine trust in AI systems and can lead to serious consequences in domains like healthcare, finance, or legal applications. Traditional prompt engineering alone is insufficient to prevent hallucinations.
**Solution:**
The Hallucination Guard pattern implements verification layers around LLM outputs. It combines techniques like grounding in trusted sources, fact-checking, confidence scoring, and explicit uncertainty flagging to minimize hallucinations.
**Participants:**
- **Source Grounding Engine**: Links LLM statements to trusted reference material
- **Fact Checker**: Verifies factual claims against reliable sources
- **Confidence Analyzer**: Assesses LLM certainty and flags potential hallucinations
- **Uncertainty Communicator**: Explicitly represents uncertainty in responses to users
**Consequences:**
- **Positive**: Significantly reduced hallucination rate
- **Positive**: Appropriate expression of uncertainty when information is limited
- **Positive**: Increased user trust through verifiable responses
- **Negative**: Higher computational cost and latency
- **Negative**: Potential for overly cautious responses
**Known Uses:**
- Medical diagnosis assistance systems
- Financial advisory applications
- Educational tutoring platforms
Prompt Template Strategy
**Context:**
Prompt engineering is both art and science, with different prompt structures yielding significantly different results for the same underlying task.
**Problem:**
Static prompts cannot adapt to different user needs, content types, or evolving LLM capabilities. Finding the optimal prompt often requires experimentation that's difficult to systematize.
**Solution:**
The Prompt Template Strategy pattern applies the Strategy pattern to prompt engineering. It defines a family of interchangeable prompt templates that can be selected dynamically based on context, user needs, or performance metrics.
**Participants:**
- **Template Registry**: Maintains available prompt templates for each task type
- **Template Selector**: Chooses the appropriate template based on context
- **Performance Monitor**: Tracks effectiveness of different templates
- **Template Evolver**: Generates and tests new template variations
**Consequences:**
- **Positive**: Enables continuous prompt optimization
- **Positive**: Adapts to different user needs and content types
- **Positive**: Facilitates systematic A/B testing of prompts
- **Negative**: Increased system complexity
- **Negative**: Potential inconsistency in responses across different templates
**Known Uses:**
- Enterprise chatbots serving diverse user populations
- Content generation platforms with varying stylistic requirements
- Educational systems adapting to different learning styles
RAG Composition
**Context:**
Retrieval-Augmented Generation (RAG) systems combine information retrieval with generative AI to ground responses in specific knowledge bases.
**Problem:**
Building effective RAG systems requires integrating multiple components (retrievers, rankers, generators) that each have different implementation options and performance characteristics.
**Solution:**
The RAG Composition pattern formalizes how to compose RAG systems from modular components. It defines interfaces between retrievers, rankers, and generators, allowing for mix-and-match capabilities while maintaining system coherence.
**Participants:**
- **Knowledge Store**: Contains the documents or information to be retrieved
- **Query Processor**: Transforms user queries into effective retrieval queries
- **Retriever**: Finds relevant documents or passages from the knowledge store
- **Ranker**: Prioritizes retrieved information by relevance
- **Context Assembler**: Constructs the prompt with retrieved information
- **Generator**: Produces the final response based on the assembled context
**Consequences:**
- **Positive**: Enables experimentation with different component combinations
- **Positive**: Facilitates incremental improvement of individual components
- **Positive**: Creates clear separation of concerns
- **Negative**: Potential integration challenges between components
- **Negative**: Performance interdependencies between components
**Known Uses:**
- Enterprise knowledge base assistants
- Research tools integrating multiple data sources
- Customer support systems with diverse product documentation
Semantic Caching
**Context:**
LLM applications often make repeated similar queries that don't require fresh computation each time, creating opportunities for performance optimization.
**Problem:**
Traditional exact-match caching is ineffective for LLM applications because queries are rarely identical even when seeking the same information. This leads to unnecessary API calls, increased costs, and higher latency.
**Solution:**
Semantic Caching stores responses along with semantic representations of queries. New queries are compared semantically to cached entries, and sufficiently similar matches return cached results, potentially with minor adaptations.
**Participants:**
- **Query Embedder**: Converts queries into semantic vector representations
- **Similarity Calculator**: Determines semantic proximity between queries
- **Cache Store**: Maintains query-response pairs with semantic metadata
- **Response Adapter**: Adjusts cached responses to match new query nuances
**Consequences:**
- **Positive**: Reduced API costs through fewer LLM calls
- **Positive**: Lower latency for semantically repeated queries
- **Positive**: Improved consistency across similar questions
- **Negative**: Potential for returning slightly misaligned responses
- **Negative**: Memory and computational overhead for semantic matching
**Known Uses:**
- Customer support chatbots handling common questions
- Educational platforms with recurring concept explanations
- Documentation assistants answering standard queries
Multimodal Orchestration
**Context:**
Modern AI applications increasingly work across multiple modalities (text, images, audio, video) requiring coordination between specialized AI models.
**Problem:**
Different modalities require different processing approaches, and information must be integrated coherently across these modalities to provide unified experiences.
**Solution:**
The Multimodal Orchestration pattern defines how specialized AI models for different modalities communicate and coordinate. It establishes protocols for cross-modal information exchange, synchronization, and integrated reasoning.
**Participants:**
- **Modal Specialists**: AI models specialized for specific modalities
- **Cross-Modal Translator**: Converts information between modality-specific representations
- **Orchestration Controller**: Coordinates processing across modalities
- **Integration Engine**: Combines insights from different modalities into coherent outputs
**Consequences:**
- **Positive**: Enables rich multi-sensory AI experiences
- **Positive**: Leverages specialized models for each modality
- **Positive**: Creates more natural human-AI interactions
- **Negative**: Increased system complexity
- **Negative**: Challenges in resolving contradictions between modalities
**Known Uses:**
- Virtual assistants processing voice, text, and visual inputs
- Content moderation systems analyzing text and images
- Accessibility tools translating between modalities
Conclusion
This comprehensive pattern catalog represents the evolution of software design thinking to address modern challenges across traditional, cloud-native, and AI domains. While building on the solid foundation established by GoF and POSA, these patterns extend into new territories shaped by distributed systems, cloud computing, containerization, and artificial intelligence.
The inclusion of the Bounded Singleton pattern addresses limitations in the classic Singleton while maintaining controlled instantiation, while the Containerization pattern family provides structured approaches to container-based deployment and orchestration challenges in modern cloud environments.
By formalizing these patterns, developers can leverage proven solutions to common problems, accelerating development while improving system quality and maintainability. As technology continues to evolve, this pattern catalog will expand to incorporate new approaches that address emerging challenges in software design and architecture.
