Integrating with External Services

Internal vs External Integrations

• Integrating internal microservices allows for easier collaboration and control over endpoints, uptime, schema, and failure modes.
• Integrating with third-party, external systems (e.g., SaaS providers or payment processors like Stripe) involves less control and increased risk.
• Reducing coupling is crucial when dealing with systems outside organizational control, in line with Gregor Hohpe’s advice on coupling and control.

Patterns for Reducing Coupling with Third-Party Systems

• Asynchronous communication and message-driven systems are recommended but not always possible with external APIs requiring synchronous REST calls.
• Direct integration with third-party APIs is possible but risky due to potential downtime, schema changes, or other disruptions.
• Introducing a batch queue in front of the external API decouples service logic and allows internal control over request handling.
• A dedicated intermediary or layer (“anti-corruption layer”) is responsible for the third-party communication, centralizing logic and shielding internal systems from direct dependency.

Anti-Corruption Layer and Caching

• The anti-corruption layer, from domain-driven design, helps translate between external and internal schemas, offering flexibility and resilience.
• For inbound data from third parties, a batch process can update a local cache, so services read from the cache with stable formatting rather than directly from the third party. This further decouples the internal system and enables more reliable operations, though at the cost of potential data staleness.

Practical Example: Payment Processing with the Saga Pattern

• For example, integrating with a payment processor via saga pattern, an order confirmation message is published to a queue.
• A dedicated payment processing layer takes this message, processes the payment, and publishes the result (payment success or failure) to another channel.
• The saga monitors this channel to act accordingly, limiting interruption from third-party failures or API changes.
• Direct synchronous calls from business logic to the processor increase the risk of system-wide failure if the external service is unavailable or changes unexpectedly.

Key Recommendations

• Always analyze integration points with systems outside your control and reduce coupling as much as possible.
• Introduce intermediary or anti-corruption layers for critical API integrations to shield core business logic.
• Be mindful that this approach adds complexity in response management and consistency but prevents cascading failures and increases resilience.
• Be intentional and thoughtful in designing integrations with third-party systems.