Integration patterns are the vocabulary of enterprise architecture. Without them, every integration becomes a custom puzzle. With them, you're applying proven solutions to recurring problems. Here are seven patterns that appear in virtually every successful enterprise integration we've designed—and when to use each one.
1. Publish-Subscribe (Pub/Sub)
The workhorse of event-driven architecture. Publishers emit events without knowing who consumes them. Subscribers receive events they've registered interest in. This decoupling is powerful—systems can evolve independently.
When a German retailer we worked with adopted pub/sub for inventory updates, they went from coordinating deployments across 12 systems to deploying independently. New consumers subscribe without touching the publisher. Old consumers unsubscribe without ceremony.
Best for:
- Event broadcasting: One event, many interested parties
- Loose coupling: Publisher doesn't need to know consumers
- Scalability: Add subscribers without touching existing systems
Watch out for:
- Message ordering: Events may arrive out of sequence
- Duplicate delivery: Design consumers to be idempotent
- Event schema evolution: Plan for backwards compatibility
2. Request-Reply
The synchronous pattern we all know. Send a request, wait for a response. Simple and intuitive, but the waiting is the problem. When the downstream system is slow or unavailable, the caller blocks.
Request-reply works for queries that need immediate answers. It struggles when you chain multiple services together—latency compounds, and any failure breaks the chain.
Every synchronous call is a bet that the downstream system is available and fast. In distributed systems, that bet loses more often than you'd like.
Best for:
- Queries: When you genuinely need the data before proceeding
- User-facing operations: Where immediate feedback is required
- Simple integrations: Two systems, clear dependency
3. Message Queue
Decouple producer from consumer with a buffer in between. The producer sends messages to a queue; consumers pull when ready. This temporal decoupling handles load spikes, enables retry logic, and lets systems operate at their own pace.
A Swiss insurance company processed claims through a message queue, allowing their legacy claims system to process at its maximum capacity while the modern frontend accepted submissions at any rate. Peak load? The queue absorbs it.
Queue variants:
- Point-to-point: One producer, one consumer per message
- Competing consumers: Multiple consumers share the workload
- Dead letter queue: Failed messages go somewhere visible
4. API Gateway
A single entry point for all client requests. The gateway handles cross-cutting concerns—authentication, rate limiting, request routing, protocol translation—so backend services don't have to.
Without a gateway, every service implements its own security, monitoring, and throttling. With a gateway, you centralize these concerns and let services focus on business logic.
Gateway responsibilities:
- Authentication/Authorization: Verify identity once at the edge
- Rate limiting: Protect backends from traffic spikes
- Request routing: Direct traffic to appropriate services
- Protocol translation: REST to gRPC, SOAP to REST, etc.
- Response aggregation: Combine multiple backend calls
5. Saga Pattern
Distributed transactions without distributed locks. When a business process spans multiple services, sagas coordinate the steps and handle failures through compensating actions rather than rollbacks.
Consider order processing: reserve inventory, charge payment, schedule shipping. If shipping fails, you need to refund the payment and release the inventory. Sagas make this explicit.
In distributed systems, you can't have atomic transactions across services. Sagas accept this reality and design for eventual consistency.
Two flavors:
- Choreography: Each service reacts to events and triggers the next step
- Orchestration: A central coordinator directs the workflow
When to use orchestration:
- Complex workflows with many steps
- Need for visibility into process state
- Frequent changes to business logic
6. Event Sourcing
Store events, not state. Instead of updating a record, append an event describing what happened. Current state is derived by replaying events. This pattern provides complete audit trails and enables temporal queries.
An Austrian financial services firm implemented event sourcing for regulatory compliance. Every state change is recorded. Auditors can reconstruct the exact state at any point in time. No "who changed what when" mysteries.
Benefits:
- Complete audit trail: Every change is recorded
- Temporal queries: What was the state at time T?
- Event replay: Rebuild read models, fix bugs retroactively
- Debugging: Reproduce issues by replaying events
Challenges:
- Event schema evolution: Old events must remain readable
- Storage growth: Events accumulate forever (by design)
- Query complexity: Current state requires projection
7. Backend for Frontend (BFF)
Different clients have different needs. Mobile apps want minimal payloads. Web apps need rich data. Admin interfaces require different views. BFF creates dedicated backends for each client type.
Instead of one API that tries to serve everyone (and serves no one well), BFF lets each client team optimize their backend. The mobile BFF returns compressed, essential data. The web BFF returns richer responses.
When BFF makes sense:
- Multiple client types: Web, mobile, IoT, partners
- Different optimization needs: Bandwidth vs. functionality
- Separate teams: Client teams own their backends
Combining Patterns
These patterns aren't mutually exclusive. Real architectures combine them. An API gateway routes requests. Some requests trigger synchronous queries. Others publish events to a message queue. Sagas coordinate multi-step processes. Event sourcing maintains audit trails.
The skill is knowing which pattern fits which problem. Over-engineering with patterns is as dangerous as under-engineering without them.
Choosing the Right Pattern
Start with the problem, not the pattern. What are the consistency requirements? What's the acceptable latency? How should failures be handled? The answers guide pattern selection.
Enterprise architects who master these patterns don't just build integrations—they build integration capabilities that the organization can rely on for years.