Bulk API, Streaming API, Apex REST API, Analytics REST API

Explanation

NTO’s integration design must efficiently handle a one-time load of over 11 million records, push real-time change alerts to three downstream systems, securely expose custom logic to five external apps, and automate nightly data processes. The optimal API set leverages asynchronous bulk loading, event-driven streaming, lightweight secure REST endpoints, and Data Cloud scheduling capabilities for end-to-end governance.

✅ Correct Option: C – Bulk API, Streaming API, Apex REST API, Analytics REST API
Bulk API supports high-volume initial data ingestion with parallel job processing and automatic chunking for millions of records. Streaming API (PushTopic or Platform Events) delivers instant notifications of Account/Contact changes to external systems without polling. Apex REST API provides secure, JSON-based exposure of custom business logic using OAuth 2.0 and named credentials. Analytics REST API enables programmatic scheduling of Data Cloud dataflows, recipes, and sync operations nightly.

❌ Incorrect Option: A – Bulk API, Chatter REST API, Apex SOAP API, Tooling API
Chatter REST API focuses on social feeds and collaboration—not record-level change detection or notifications. Apex SOAP API is deprecated for new development; it’s verbose, slower, and harder to secure than REST. Tooling API manages metadata and CI/CD—not data movement or business logic.

❌ Incorrect Option: B – Bulk API, Chatter REST API, Apex REST API, Analytics REST API
Substitutes Streaming API with Chatter REST API, which cannot monitor or push DML events. Fails the real-time notification requirement entirely.

❌ Incorrect Option: D – Bulk API, Streaming API, Apex SOAP API, Analytics REST API
Replaces Apex REST API with outdated Apex SOAP API—leading to larger payloads and complex WSDL management. SOAP lacks modern security and performance advantages of REST for external app integration.

📚 Reference:
Introduction to Bulk API 2.0 and Bulk API
Getting Started with Streaming API
Exposing Apex Classes as REST Web Services
CRM Analytics REST API Overview

Use middleware queuing and buffering to insulate Salesforce from system outages.

Explanation:

When integrating Salesforce with external systems, service availability cannot always be guaranteed. If the manufacturing system web-service goes down, the integration should gracefully handle outages without losing critical data. Here’s why option A is correct:

Middleware Queuing and Buffering:
Middleware platforms (like MuleSoft, Dell Boomi, or Informatica) can queue or buffer requests when the target system is unavailable.
Salesforce can continue sending messages to the middleware, and the middleware retries delivery once the external system is back online.
This decouples Salesforce from system downtime and ensures no data is lost.

Why not the other options?

B. Platform Event replayId and scheduled Apex:
Platform Events are great for event-driven integrations, but replaying events doesn’t solve the problem of callouts failing due to the target system being down.

C. @future and scheduled Apex retries:
This is a possible workaround for small-scale failures, but Apex retry logic is limited (governor limits, retries not guaranteed for long outages). It’s not suitable for multi-day outages.

D. Outbound Messaging retries:
Outbound Messaging only retries for a limited number of times over a short period (up to 24 hours). It won’t cover outages lasting several days.

Key takeaway:
For long-duration outages, middleware with queuing and buffering is the most reliable, scalable solution.

Reference:
Salesforce Architects Guide: Integration Patterns
Queue-Based Load Leveling Pattern: “Use a queue to decouple producers and consumers, enabling the system to handle temporary service outages without losing data.”

Use ESB tool with Data Virtualization pattern, expose OData endpoint, and then use Salesforce Connect to consume and display the External Object alongside with the Caseobject.

Explanation

This solution is the best fit because it maximizes declarative configuration and directly addresses the requirement for on-demand access to large volumes of external data (20 million records) without migrating the data into Salesforce.

Data Virtualization / Salesforce Connect:
The key requirement is to allow call center agents to view related historical items from the Historical Data Store on demand. The most efficient way to achieve this without moving 20 million records into Salesforce is Data Virtualization. Salesforce Connect uses this pattern to access data stored outside of Salesforce in real-time.

OData Endpoint:
Salesforce Connect relies on the external system exposing the data via a supported protocol. OData is one of the primary protocols used by Salesforce Connect to create External Objects in the Salesforce org.

External Objects & Declarative Configuration:
Once the External Object is configured using Salesforce Connect (a largely declarative process), the historical data records behave much like standard Salesforce records. They can be displayed declaratively using related lists on the Case object page layout, meeting the agents' request to view related items, all with minimal to no Apex code.

❌ Why other options are incorrect:

B. Use an ESB tool with a fire and forget pattern and then publish a platform event...
Fire-and-Forget is an asynchronous pattern for sending data and expecting no immediate reply. It's unsuitable for a real-time request-and-display requirement like viewing historical records when a user clicks on a case.

C. Use an ESB tool with Request-Reply pattern and then make a real-time Apex callout...
This uses the correct Request-Reply pattern for real-time data access. However, making a direct Apex callout and then handling the data to display a component requires significant custom Apex code and Lightning/Aura/LWC development, which violates the requirement to maximize declarative configuration.

D. Use an ETL tool with a Batch Data Synchronization pattern to migrate historical data into Salesforce...
Migrating 20 million records (and growing) into Salesforce is highly inefficient, expensive, and risks hitting storage and performance limits. It defeats the purpose of offloading historical data. The Batch Data Synchronization pattern is for keeping data sets current, not for on-demand access to massive archives.

Require the Apex REST API Clients to implement the HttpCalloutMock.

Implement HttpCalloutMock to return responses per RAML specification.

Explanation:

Northern Trail Outfitters aims to ensure that Apex REST API clients adhere to RAML specifications, which define the structure and content of API request and response payloads. To confirm this adherence during unit testing, the integration architecture must include mechanisms to simulate API interactions and validate responses against the RAML contract. Let’s analyze the options:

A. Call the Apex REST API Clients in a test context to get the mock response.

This option is incorrect because simply calling the Apex REST API clients in a test context to retrieve a mock response does not inherently ensure adherence to RAML specifications. Without a specific mechanism to validate the response structure against RAML, this approach lacks the rigor needed to confirm compliance with the field-level definitions in the RAML contract.

B. Require the Apex REST API Clients to implement the HttpCalloutMock.

This is correct. The HttpCalloutMock interface in Salesforce allows developers to simulate external HTTP callouts during unit testing, which is essential for testing Apex REST API clients without making actual external calls. By requiring clients to implement HttpCalloutMock, the architecture ensures that tests can control and validate the mock responses, enabling verification that the client handles requests and responses as per the RAML specifications. This setup supports repeatable, isolated tests that align with the API contract.

C. Call the HttpCalloutMock implementation from the Apex REST API Clients.

This option is incorrect because Apex REST API clients do not directly call the HttpCalloutMock implementation. Instead, the Salesforce testing framework uses the Test.setMock() method to associate the HttpCalloutMock implementation with HTTP callouts made by the client during tests. The client code itself remains unaware of the mock implementation, making this option technically inaccurate.

D. Implement HttpCalloutMock to return responses per RAML specification.

This is correct. Implementing the HttpCalloutMock interface to return mock responses that conform to the RAML specifications ensures that unit tests validate the Apex REST API client’s behavior against the expected request and response payloads. By crafting mock responses that mirror the RAML-defined structure (e.g., specific fields, data types, and formats), the integration architect can confirm that the client correctly processes API responses as per the contract, catching any deviations during testing.

Why B and D?

B ensures the architecture mandates the use of HttpCalloutMock for testing, which is a Salesforce best practice for mocking external API calls.

D complements this by specifying that the mock implementation must align with RAML specifications, ensuring the client’s handling of requests/responses is tested against the API contract.

References:

Salesforce Developer Documentation: Testing HTTP Callouts – Explains the use of HttpCalloutMock for simulating HTTP callouts in unit tests.

Salesforce Trailhead: Test Apex Callouts – Covers best practices for mocking and testing REST API integrations.

RAML Official Documentation: RAML Specification – Details how RAML defines API contracts, including field-level request/response specifications, which can be used to structure mock responses.

Streaming API

Explanation

The question specifies that the Integration Architect has already recommended using a Salesforce Platform Event to provide a near real-time feed. The key is to understand which API is specifically designed to consume or subscribe to these events from an external system.

Let's evaluate the options:

A. Tooling API:
This is incorrect. The Tooling API is used for building custom development tools and applications that manage Salesforce metadata. It is not designed for subscribing to real-time event feeds.

B. Streaming API:
This is correct. The Streaming API is the generic mechanism for external clients to subscribe to events. It uses the CometD protocol to maintain a long-lived connection, allowing the learning system to listen for and receive Platform Event messages the moment they are published in Salesforce. This provides the "near real-time" feed that UC requested.

C. REST API:
This is incorrect for the subscription role. The REST API can be used to publish a Platform Event from an external system to Salesforce, but it cannot be used to listen for events. An external system cannot use the REST API to get a continuous, real-time feed of events; it would have to constantly poll, which is inefficient and not real-time.

D. SOAP API:
This is incorrect for the same reason as the REST API. The SOAP API can be used to publish events to Salesforce, but it cannot act as a subscriber to receive a real-time push of events.

Key Concept

The key concept is the distinction between publishing and subscribing to Platform Events.
Publishing an Event: Sending an event message into the Salesforce Event Bus. This can be done from Apex, Process Builder, Flow, or externally via the REST API or SOAP API.
Subscribing to an Event: Listening for and receiving event messages from the Salesforce Event Bus. This is done exclusively through the Streaming API for external clients.
The learning system needs to subscribe to the Student Registration event, making the Streaming API the only correct choice.

Reference
This is a fundamental aspect of the Salesforce event-driven architecture. The official Salesforce "Streaming API" Developer Guide states that it "enables you to receive notifications for changes in Salesforce data... using a publish-subscribe model." It is the designated API for external systems to subscribe to Platform Events, PushTopics, and Generic Streaming channels to receive real-time data.