6 Integration Patterns That Look Good on Paper and What Happens When They Hit Production

In most enterprise systems, integrations don’t fail immediately. They fail slowly. Everything works fine at first, APIs respond quickly, workflows look clean, and dependencies seem manageable. Then traffic grows, systems evolve, and edge cases appear. That’s when the cracks start to show.

In my experience, these failures are rarely caused by tools. They come from how integration patterns are applied without considering real-world conditions like latency, retries, partial failures, and security boundaries.

Instead of covering every possible pattern, I’ll focus on six patterns that show up in almost every architecture, along with what they look like in practice and where they tend to break.

1. Request–Response (Synchronous APIs)

One system calls another and waits for a response before continuing.

Example: A mobile app calls an API to check order status and displays the result immediately.

Where it works:

• Real-time user interactions
• Simple lookups
• Fast, predictable systems

Where it fails:

• When the API calls multiple downstream systems
• When one dependency becomes slow
• When used for long-running operations (like invoice processing)

Example failure:

An order API calls inventory -> pricing -> shipping -> tax systems. One slow system delays everything and causes timeouts.

Lesson:

Synchronous flows are easy to design but fragile under dependency chains. Use them only where response time is predictable.

2. Event Driven (Publish and Subscribe)

A system publishes an event, and multiple systems react independently.

Example: When an order is placed, the “Order Creation” event triggers the Inventory update, Email notification, and Shipping process flows.

Where it works: 

• Decoupling systems
• Scaling across multiple consumers
• Real-time updates

Where it fails:

• When events are processed more than once
• When consumers depend on strict ordering

Example failure:

A payment event is processed twice, causing duplicate charges because the consumer didn’t handle duplicates.

Lesson:

Event-driven systems require idempotency and clear event contracts. Without that, they introduce silent data issues.

3. Scatter Gather (Parallel Processing)

A request is split into multiple parallel calls, and then the results are combined.

Example:

A dashboard API fetches orders from one system, customer data from another, and shipment status from a third system.

Where it works:

• Aggregating independent data
• Improving performance through parallel calls

Where it fails:

• When one system is slow
• When partial results are hard to handle

Example failure:

Two systems respond quickly, but the last one takes longer; the entire API response is delayed, impacting user experience.

Lesson:

Parallelism improves speed only when all systems perform consistently. Otherwise, it exposes the weakest dependency.

4. Retry Pattern

Automatically retrying failed operations.

Example:

If a payment API fails due to a network issue, the system retries the request after a short delay.

Where it works:

• Temporary outages
• Network glitches
• Short-lived failures

Where it fails:

• When retries overload a struggling system
• When operations are not safe to repeat

Example failure:

A retry mechanism reprocesses a payment request multiple times, leading to duplicate transactions.

Lesson:

Retries must be controlled and aware of business impact, not blindly repeated.

5. API Facade

A single API layer hides multiple backend systems.

Example:

A “customer API” provides one endpoint, even though it pulls data from CRM, billing, and support systems.

Where it works:

• Simplifying client interactions
• Standardizing access
• Hiding legacy complexity

Where it fails:

• When too much logic is added
• When it becomes a central bottleneck

Example failure:

The facade starts handling validation, transformation, orchestration, and business logic, making it difficult to scale or maintain.

Lesson:

A facade should simplify access, not centralize complexity.

6. Orchestration vs. Choreography

Two ways to manage workflows:

• Orchestration: One central service controls the flow
  • Example: An order service calls payment -> inventory -> shipping in sequence
  • Where orchestration works:
    • Clear control
    • Easier to understand flows
  • Where orchestration fails:
    • Becomes a bottleneck
    • Hard to scale
• Choreography: Each service reacts to events independently
  • Example: Order event triggers payment -> payment triggers inventory -> inventory triggers shipping
  • Where choreography works:
    • Better scalability
    • Loose coupling
  • Where choreography fails:
    • Difficult to debug
    • Hard to track end-to-end flow

Example failure:

In choreography, a missing event causes part of the workflow to silently stop with no visibility.

Lesson:

There is no perfect choice. It’s a trade-off between control and flexibility.

Key Takeaways

• Simple patterns become complex under scale.
• Dependencies define system behavior more than code.
• Event-driven systems need discipline, not just adoption.
• Retries and parallelism can create new failure modes.
• Centralization simplifies control but limits scalability.
• Observability is critical in distributed systems.

Final Thoughts

Integration architecture is not about connecting systems. It’s about anticipating how they behave when things don’t go as expected. 

Most issues don’t appear during development. They appear later:

• Under load
• During partial failures
• When systems evolve independently

The patterns themselves are not the problem. The problem is applying them without considering real-world conditions. Good architecture is less about choosing the “right” pattern and more about understanding the trade-offs each pattern introduces.