Integration Patterns

Overview

Modern organizations rarely operate a single application.

Most enterprises depend on dozens or even hundreds of systems that must exchange information and work together.

Architects frequently face questions such as:

Integration Patterns provide proven solutions to recurring integration challenges that appear across industries and technologies.

A Running Example

Throughout this page we will use a healthcare diagnostics platform as a running example.

The platform must interact with multiple internal and external systems.

Each system may use different protocols, formats, availability models, and ownership structures.

Integration patterns help manage these interactions in a predictable and maintainable manner.

Why Integration Patterns Matter

Integration is often one of the most complex areas of enterprise architecture.

Systems evolve independently, failures occur unexpectedly, formats differ, and performance characteristics vary significantly.

Challenge	Typical Impact
Different Data Formats	Transformation Required
Independent Releases	Compatibility Risks
System Failures	Processing Interruptions
Network Issues	Communication Delays
Scaling Requirements	Throughput Challenges

Without proper patterns, integrations often become difficult to understand, maintain, and troubleshoot.

Integration Challenges

Designing integrations is rarely about choosing a technology.

It is often about solving practical business and operational problems.

Format Differences

Different systems frequently use different message structures and standards.

Availability Differences

One system may be online while another becomes temporarily unavailable.

Ownership Differences

Partner systems evolve according to their own priorities and schedules.

Performance Differences

Some systems respond immediately while others require minutes or hours.

Failure Handling

Every integration must consider what happens when communication fails.

Understanding these challenges is often more important than understanding individual integration patterns.

Choosing An Integration Pattern

There is no universally correct integration pattern.

The right approach depends on business requirements, operational constraints, responsiveness requirements, and failure tolerance.

Requirement	Possible Direction
Immediate Response Required	Request-Reply
Multiple Consumers	Publish-Subscribe
Format Differences	Message Translator
Dynamic Routing	Content-Based Router
Response Aggregation	Aggregator
Large Payloads	Claim Check

Patterns should be selected because they solve specific problems, not because they are popular.

Point-To-Point Integration

Point-To-Point integration is the simplest form of system communication.

One system communicates directly with another system.

There are no intermediaries, brokers, or routing components involved.

Benefits:

• Simple To Implement
• Low Initial Cost
• Easy To Understand
• Fast Communication

Challenges:

• Tight Coupling
• Difficult To Scale
• Connection Explosion As Systems Grow
• Change Impacts Multiple Systems

Works Well When:

• Only A Few Systems Exist
• Requirements Are Simple
• Limited Integrations Are Required

Avoid When:

• Many Systems Must Communicate
• Frequent Changes Are Expected
• Enterprise Scale Is Required

Shared Database Integration

Shared Database integration occurs when multiple systems access the same database.

This approach is common in enterprise environments because it appears simple.

Benefits:

• Single Source Of Data
• Simple Initial Implementation
• Minimal Integration Logic

Challenges:

• Strong Coupling
• Shared Ownership Problems
• Schema Change Risks
• Limited Service Autonomy

Works Well When:

• Applications Are Closely Related
• Ownership Is Centralized
• Simple Solutions Are Needed

Avoid When:

• Independent Teams Exist
• Service Ownership Matters
• Microservices Are Being Adopted

File Transfer Integration

File Transfer remains one of the most widely used integration approaches in large enterprises.

Despite modern APIs and messaging platforms, organizations still exchange significant amounts of information using files.

A system generates a file and another system processes it later.

Benefits:

• Simple Integration Model
• Works Across Organizations
• Handles Large Data Volumes
• Supports Batch Processing

Challenges:

• Not Real-Time
• Delayed Processing
• Versioning Challenges
• Error Handling Complexity

Works Well When:

• Batch Processing Is Acceptable
• Large Data Volumes Exist
• External Organizations Participate

Request-Reply

Request-Reply is the most familiar integration style.

A system sends a request and expects an immediate response.

Examples include:

• Patient Retrieval
• Insurance Validation
• Pricing Requests
• Account Verification

Benefits:

• Simple Interaction Model
• Immediate Results
• Easy To Understand

Challenges:

• Dependency On Availability
• Network Latency
• Cascading Failures
• Limited Scalability

Works Well When:

• Immediate Answers Are Required
• User Experience Depends On Real-Time Responses
• Low Latency Is Needed

Avoid When:

• Long Processing Times Exist
• Consumers Can Work Asynchronously
• Temporary Delays Are Acceptable

Publish-Subscribe

Publish-Subscribe allows systems to react to events without creating direct dependencies.

The producer publishes information without knowing who will consume it.

Benefits:

• Loose Coupling
• Easy Expansion
• Independent Consumers
• Scalable Integrations

Challenges:

• Event Tracking Complexity
• Ordering Challenges
• Eventual Consistency
• Debugging Difficulties

Works Well When:

• Multiple Consumers Need Information
• Asynchronous Processing Is Acceptable
• Future Expansion Is Expected

Avoid When:

• Immediate Responses Are Required
• A Single Consumer Exists

Message Channel

A Message Channel provides a dedicated pathway through which messages travel between producers and consumers.

Rather than communicating directly, systems communicate through the channel.

The channel becomes a controlled communication boundary.

Benefits:

• Decoupled Communication
• Improved Flexibility
• Easier Monitoring
• Independent Evolution

Challenges:

• Operational Overhead
• Additional Infrastructure
• Governance Requirements

Works Well When:

• Multiple Producers Exist
• Multiple Consumers Exist
• Long-Term Integration Flexibility Is Required

Message Router

As integrations grow, deciding where messages should be delivered becomes increasingly important.

A Message Router determines the destination of a message and forwards it appropriately.

Rather than allowing producers to decide delivery destinations, routing logic is centralized.

Benefits:

• Centralized Routing Logic
• Simplified Producers
• Improved Maintainability
• Easier Expansion

Challenges:

• Additional Infrastructure
• Potential Routing Bottleneck
• Routing Logic Management

Works Well When:

• Multiple Destinations Exist
• Routing Rules Frequently Change
• Integration Complexity Is Growing

Avoid When:

• Only One Destination Exists
• Routing Rules Never Change

Content-Based Router

A Content-Based Router examines message content and determines routing based on business rules.

The destination depends on the information contained inside the message.

In the diagnostics platform, different test types may require different downstream processing workflows.

Benefits:

• Dynamic Routing
• Flexible Processing Flows
• Business Rule Driven Decisions

Challenges:

• More Complex Routing Logic
• Rule Maintenance
• Growing Decision Complexity

Works Well When:

• Multiple Processing Paths Exist
• Business Rules Drive Routing
• Destinations Depend On Payload Data

Avoid When:

• Routing Is Static
• A Single Processing Path Exists

Message Translator

Different systems frequently use different data models, formats, and conventions.

A Message Translator converts information from one format into another.

For example, an external laboratory vendor may send data that differs from the platform’s internal model.

The translator creates a consistent representation that downstream services understand.

Benefits:

• Reduced Integration Coupling
• Format Independence
• Vendor Isolation
• Simplified Internal Design

Challenges:

• Mapping Complexity
• Version Management
• Additional Processing Overhead

Works Well When:

• Systems Use Different Formats
• External Partners Exist
• Data Standardization Is Required

Avoid When:

• Formats Already Match
• No Transformation Is Needed

Message Filter

Not every message is relevant to every consumer.

A Message Filter removes messages that do not satisfy specific criteria.

This prevents downstream systems from processing unnecessary information.

Benefits:

• Reduced Processing Load
• Simplified Consumers
• Improved Efficiency

Challenges:

• Filter Logic Maintenance
• Potential Filtering Errors

Works Well When:

• Large Message Volumes Exist
• Only Subsets Of Data Are Required
• Noise Reduction Is Needed

Avoid When:

• Consumers Need All Messages
• Filtering Rules Are Unclear

Aggregator

An Aggregator combines information from multiple sources into a single response or message.

This pattern is common when users need a unified view of distributed information.

Instead of requiring consumers to call every backend system individually, the aggregator performs the consolidation.

Benefits:

• Simplified Consumption
• Reduced Client Complexity
• Consolidated Responses

Challenges:

• Dependency On Multiple Systems
• Potential Latency Increases
• Partial Failure Handling

Works Well When:

• Information Exists Across Systems
• Consumers Need Unified Views
• Backend Complexity Must Be Hidden

Avoid When:

• Consumers Need Independent Data Access
• Aggregation Adds Unnecessary Complexity

Splitter

A Splitter divides a large message or request into multiple smaller units that can be processed independently.

This pattern is useful when different parts of the message require separate processing.

For example, a diagnostic order containing many tests may be broken into independent requests for multiple laboratory systems.

Benefits:

• Parallel Processing
• Improved Scalability
• Flexible Work Distribution
• Independent Processing

Challenges:

• Result Coordination
• Tracking Complexity
• Reassembly Requirements

Works Well When:

• Large Requests Exist
• Parallel Processing Is Valuable
• Independent Workflows Are Needed

Avoid When:

• Requests Are Already Small
• Splitting Adds More Complexity Than Value

Claim Check

Sometimes messages become too large to efficiently transport through an integration channel.

The Claim Check pattern stores the large payload separately and sends only a lightweight reference.

For example, medical images, laboratory reports, PDFs, and diagnostic attachments can become very large.

Instead of embedding the entire payload inside a message, the integration transmits a reference.

Benefits:

• Smaller Messages
• Reduced Network Overhead
• Improved Throughput
• More Efficient Message Processing

Challenges:

• Additional Storage Management
• Reference Tracking
• Payload Retrieval Complexity

Works Well When:

• Large Documents Exist
• Images Are Exchanged
• Message Size Limits Exist

Avoid When:

• Payloads Are Small
• Retrieval Complexity Adds Limited Value

Dead Letter Channel

No integration is perfect. Messages occasionally fail processing due to temporary outages, invalid data, or unexpected conditions.

A Dead Letter Channel captures failed messages for later investigation.

Benefits:

• Prevents Message Loss
• Supports Recovery
• Improves Operational Visibility
• Simplifies Troubleshooting

Challenges:

• Operational Monitoring Required
• Recovery Strategy Needed
• DLQ Growth Management

Works Well When:

• Reliable Message Processing Is Important
• Failures Must Be Investigated
• Data Loss Is Unacceptable

Avoid When:

• Messages Are Non-Critical
• Failure Handling Is Not Required

Idempotent Receiver

Distributed systems frequently deliver the same message more than once.

An Idempotent Receiver ensures duplicate messages do not produce duplicate outcomes.

For example, a billing event processed twice could create duplicate charges.

An idempotent receiver prevents this outcome.

Benefits:

• Duplicate Protection
• Safer Retries
• Improved Reliability
• Operational Confidence

Challenges:

• Tracking Processed Messages
• Additional Storage Requirements
• Duplicate Detection Logic

Works Well When:

• Retries Are Common
• At-Least-Once Delivery Exists
• Financial Or Business Operations Are Involved

Avoid When:

• Duplicates Cannot Occur
• Processing Is Naturally Idempotent

Integration Pattern Combinations

Enterprise integrations rarely use a single pattern.

Most production solutions combine multiple patterns to address different requirements.

Publish-Subscribe + Content-Based Router

Translator + Request-Reply

Splitter + Aggregator

Publish-Subscribe + DLQ + Idempotent Receiver

This combination-based thinking is how real integration architectures evolve.

Pattern Selection Framework

A common architect responsibility is selecting the simplest pattern that satisfies business requirements.

Requirement	Pattern To Consider
Immediate Response	Request-Reply
Multiple Consumers	Publish-Subscribe
Dynamic Routing	Content-Based Router
Format Transformation	Message Translator
Data Consolidation	Aggregator
Parallel Work Distribution	Splitter
Large Payloads	Claim Check
Failure Handling	Dead Letter Channel
Duplicate Prevention	Idempotent Receiver

Real-World Case Study

Consider a diagnostic order submitted through the healthcare platform.

External partners use different message structures.

Large diagnostic images are stored separately.

Failures are captured for investigation.

Duplicate events are ignored safely.

This example demonstrates how multiple integration patterns work together to create a resilient enterprise integration solution.

Integration Review Checklist

The following checklist can be used during architecture reviews and integration design sessions.

Integration Canvas

The Integration Canvas provides a practical framework for documenting integration decisions.

Area	Example
Source System	Order Service
Target System	Laboratory Vendor
Integration Style	Publish-Subscribe
Pattern Selected	Translator + Router
Transformation Needs	Vendor Mapping
Failure Strategy	Retry + DLQ
Duplicate Handling	Idempotent Processing
Monitoring	Metrics + Alerts
Ownership	Integration Team
Primary Risk	Partner Availability

Common Anti-Patterns

Point-To-Point Spaghetti

Every system connects directly to every other system, creating a dependency nightmare.

Shared Database Everywhere

Multiple systems depend on the same schema and ownership becomes unclear.

Synchronous Everything

Every operation waits on another system, creating latency and cascading failures.

No Retry Strategy

Temporary failures immediately become business failures.

No Dead Letter Channel

Failed messages disappear without visibility.

No Idempotency

Duplicate messages cause inconsistent business behavior.

Hidden Dependencies

Critical integrations are undocumented and difficult to maintain.

No Monitoring

Failures occur without detection until business users report them.

How Patterns Connect

Integration patterns influence system scalability, reliability, security, observability, and operational complexity.

As organizations grow, integration architecture often becomes one of the most important factors influencing overall system success.

Key Takeaway