Slide 1
Slide 1 text
Integration Platform
Duvan Andres Villadiego Hoyos
Slide 2
Slide 2 text
Problem
Slide 3
Slide 3 text
Application need an Integration Platform
We are designing an integration platform for an application that needs to interact
with multiple external services.
Since we cannot predict how long external services will take to process each
request, the system must support long-running operations.
Because this platform is a complement to the main application, integration
processing must not directly affect the performance of the core system.
Slide 4
Slide 4 text
Requirements and
Constraints
Slide 5
Slide 5 text
Business Requirements
● The system must integrate with third-party services such as payment providers, shipping
services, and notification platforms.
● New integrations should be added without affecting the rest of the system.
● Integration failures must not stop the core business operations.
Slide 6
Slide 6 text
Functional Requirements
● The module must send requests to external APIs.
● The module must receive and process responses from external systems.
● The system must handle different integration types (REST APIs, webhooks, messaging
systems).
● The module must retry failed requests when external services are temporarily unavailable.
● The module must log all integration requests and responses.
Slide 7
Slide 7 text
Technical Constraints
● The system must use REST APIs to communicate with external services.
● The system must support asynchronous processing for long-running integrations.
● All communication with external services must use HTTPS.
● The system must implement timeout and retry mechanisms.
Slide 8
Slide 8 text
Proposals
Slide 9
Slide 9 text
1. Synchronous Integration Service
A dedicated microservice exposes an API that allows other services to request integrations.
The request specifies:
● The type of integration (payment, shipping, notifications).
● The provider to use.
The integration service communicates with the external provider and returns the result.
Advantages:
● Simple architecture.
● Easy to implement.
● Direct communication.
Limitations:
● External service latency affects response time.
● Failures can impact the caller service.
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
2. Asynchronous Integration Processor
Requests are stored in a database and processed by a worker using a state machine pattern that tracks the lifecycle of each
integration.
Example lifecycle:
Pending → Processing → Completed → Failed
Advantages:
● More resilient.
● Better for long-running integrations.
● Allows retries and failure recovery.
Limitations:
● Higher architectural complexity.
● Requires state management.
● Highly database queries that can saturate the database core.
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
Decision - Asynchronous Integration Processor
Why?
Based on the following requirement:
● The system must support asynchronous processing for long-running integrations.
We can assume that many integrations may take a significant amount of time to complete. Because of this, a solution that does not
block the core system while waiting for external services is a better architectural choice.
Main Pros:
● Higher resilience when interacting with external systems.
● Better support for long-running operations.
● Prevents blocking core system processes.
Main Const:
● Higher initial complexity.
● Potential database saturation if requests are not managed properly.