MENU
An enterprise architect has requested the Salesforce integration architect to review the following (see diagram and description) and provide recommendations after carefully considering all constraints of the enterprise systems and Salesforce Platform limits.
About 3,000 phone sales agents use a Salesforce Lightning user interface (UI) concurrently to check eligibility of a customer for a qualifying offer.
There are multiple eligibility systems that provide this service and are hosted externally.
However, their current response times could take up to 90 seconds to process and return (there are discussions to reduce the response times in the future, but no commitments are made).
These eligibility systems can be accessed through APIs orchestrated via ESB (MuleSoft).
All requests from Salesforce will have to traverse through the customer's API Gateway layer, and the API Gateway imposes a constraint of timing out requests after 9 seconds.
Which recommendation should the integration architect make?
The primary architectural challenge in this scenario is the massive discrepancy between the backend response time (up to 90 seconds) and the API Gateway timeout constraint (9 seconds). In any synchronous integration pattern, the connection must remain open across the entire path; if the API Gateway closes the connection at 9 seconds, a standard Salesforce 'Request-Reply' callout will fail long before the 90-second eligibility check is complete.
Option A is non-viable because synchronous polling at a high scale (3,000 concurrent users) would likely hit Salesforce concurrent request limits and place an immense, unnecessary load on the API Gateway. Option B, using Continuation, is designed to handle long-running callouts (up to 120 seconds) without blocking Salesforce threads, but it still requires the external connection path to remain open. It does not bypass the 9-second timeout imposed by the customer's API Gateway.
The optimal recommendation is Option C, which implements an Asynchronous Request-Reply pattern using Platform Events and the empAPI.12
Request Phase: The Salesforce UI initiates the request. To bypass the 9-second gateway timeout, the ESB (MuleSoft) should be configured to receive the request3 and immediately return an acknowledgment (e.g.,4 HTTP 202 Accepted). This allows the initial Salesforce callout to complete successfully within the 9-second window.56
Processing Phase: MuleSoft then proceeds with the long-running (up to 90 seconds) call to the external eligibility systems.78
Callback Phase (Remote Call-In)9: Once the eligibility result is received, MuleSoft calls back into Salesforce via the REST API to publish a Platform Event containing the result.10
UI Update (empA11PI): The 3,000 sales agents' browsers, having subscribed to the event channel using the empAPI (Lightning's built-in library for streaming events), receive the notification in real-time. The UI then updates to display the 'Display Response' step.
This event-driven architecture effectively 'insulates' Salesforce and the API Gateway from the backend's high latency, ensures scalability for 3,000 concurrent users, and provides a seamless, real-time user experience without hitting governor limits or timeout constraints.
==========