Q2. What is the difference between synchronous and asynchronous integration?

Answer

The primary difference between synchronous and asynchronous integration is whether the calling system waits for a response.

Synchronous Integration

The caller sends a request and waits until the response is received.

Characteristics

• Real-time
• Immediate feedback
• Simpler user experience
• Higher dependency on external system availability

Example

A customer enters a postal code on an Experience Cloud portal. Salesforce immediately calls an address validation service and displays the validated address. The user cannot continue until the response is received.

Asynchronous Integration

The caller sends the request and continues processing without waiting for a response.

Characteristics

• Better scalability
• More resilient
• Supports high-volume processing
• Increased implementation complexity

Example

When an insurance claim is submitted, Salesforce publishes a Platform Event.

Several downstream systems process the claim:

• Policy system
• Fraud detection system
• Analytics platform

The customer receives confirmation immediately while processing continues in the background.

Architect Perspective

One of the most common integration mistakes is using synchronous integrations for high-volume business processes.

For example, integrating Salesforce with SAP using synchronous REST APIs for every transaction may work initially, but performance deteriorates as volume grows.

In enterprise environments, architects generally prefer asynchronous integration whenever business requirements permit because it provides better scalability and fault tolerance.

Interview Tip

When discussing integration design, always mention:

• User experience
• Scalability
• Reliability

Interviewers want to see trade-off analysis rather than technology knowledge alone.

Q3. What factors do you consider when selecting an integration pattern?

Answer

Selecting an integration pattern is one of the most important architectural decisions. I evaluate the following factors:

1. Business Criticality

What happens if the integration fails?

Example

A payment authorization integration is business critical because revenue generation depends on it.

2. Latency Requirements

How quickly must data be available?

Example

• Address validation may require sub-second response times.
• Sales reporting data may tolerate several hours of delay.

3. Transaction Volume

How much data is exchanged?

Example

Processing 10 records per day differs significantly from processing 10 million records daily.

4. Data Ownership

Which system owns the data?

Example

SAP may be the system of record for products while Salesforce owns opportunities and customer interactions.

5. Reliability Requirements

Must every transaction be delivered?

Example

• Order creation events usually require guaranteed delivery.
• Marketing campaign events may tolerate occasional failures.

6. Security and Compliance

Does the integration involve sensitive data?

Example

Healthcare integrations involving PHI may require encryption, audit trails, and mutual TLS.

Real Project Example

In one project, Salesforce needed to synchronize customer information with SAP. Initially, the business requested synchronous APIs.

After analysis, we identified:

• 500,000 customers
• Multiple downstream systems
• Near real-time requirements

Instead of synchronous APIs, we implemented:

• Platform Events
• MuleSoft
• Guaranteed delivery queues

The architecture scaled significantly better and reduced operational risk.

Architect Perspective

Integration architecture should be driven by business requirements, not technology preferences.

Q4. Explain Request-Reply vs Fire-and-Forget Integration Patterns.

Answer

These are two of the most commonly used integration patterns in enterprise systems.

Request-Reply

The calling application waits for a response before continuing processing.

Example

• A user submits a loan application in Salesforce.
• Salesforce calls a credit bureau API.
• The credit score is returned immediately.
• The loan officer can continue only after receiving the score.

Advantages

• Immediate feedback
• Simpler business process
• Easier user experience

Challenges

• Dependency on external system availability
• Increased latency
• Reduced scalability

Fire-and-Forget

Salesforce sends information without waiting for a response. The system can continue with the next action.

Example

When an Opportunity is Closed Won, Salesforce publishes an event to MuleSoft.

MuleSoft updates:

• SAP
• ERP
• Data Warehouse

The salesperson does not wait for processing.

Advantages

• Highly scalable
• Better resilience
• Decoupled architecture

Challenges

• More complex monitoring
• Eventual consistency

Architect Perspective

Request-Reply should be used only when users genuinely require an immediate response.

For high-volume business processes, Fire-and-Forget is usually preferred.

Q5. What is Data Virtualization and when should it be used?

Answer

Data Virtualization allows Salesforce to access external data without storing it inside Salesforce.

The data remains in the source system and is retrieved on demand.

Common Technologies

• Salesforce Connect
• OData Services
• External Objects

Example

A manufacturing company stores inventory in SAP. Instead of synchronizing 10 million inventory records into Salesforce, users view inventory information directly from SAP using External Objects.

Advantages

• No data duplication
• Reduced storage costs
• Real-time visibility
• Single source of truth

Challenges

• External system availability
• Query performance
• Security considerations

Architect Perspective

Use Data Virtualization when:

• External system owns the data.
• Large datasets exist.
• Real-time access is required.

Avoid Data Virtualization when users need offline access or heavy reporting.

Q6. What are the advantages and disadvantages of Point-to-Point integrations?

Answer

Point-to-point integration connects two systems directly.

Example

Salesforce directly calls SAP APIs.

Advantages

• Quick implementation
• Lower initial cost
• Simple architecture for small environments

Disadvantages

As systems increase, complexity grows exponentially.

For example:

Salesforce integrates with:

• SAP
• ERP
• Marketing Platform
• Data Warehouse
• Billing System

Soon dozens of connections exist. Changes in one system affect multiple integrations.

Real Project Example

A client had:

• Salesforce
• SAP
• Oracle ERP
• ServiceNow
• Marketing Cloud

Over 40 direct integrations existed. Maintenance became extremely difficult.

We introduced MuleSoft as a central integration layer and reduced integration complexity significantly.

Architect Perspective

Point-to-point integrations are acceptable for small organizations.

Enterprise organizations should favor API-led or event-driven architectures to avoid long-term technical debt.

Q7. What are the benefits of a Hub-and-Spoke integration architecture?

Answer

A Hub-and-Spoke architecture uses a central integration layer (hub) through which all systems communicate instead of connecting directly with each other.

Architecture Example

Salesforce
    |
SAP ---- MuleSoft ---- Data Warehouse
    |
ServiceNow
    |
Marketing Cloud

In this architecture, Salesforce communicates with MuleSoft rather than directly integrating with every downstream application.

Benefits

1. Reduced Complexity

Instead of building multiple point-to-point integrations, each system only needs one connection to the hub.

2. Centralized Monitoring

All integrations can be monitored from a single location.

3. Reusable Services

Common functionality can be reused across multiple integrations.

4. Easier Maintenance

Changes to downstream systems can often be handled within the hub without impacting Salesforce.

Real Project Example

A healthcare client had integrations with:

• Salesforce
• SAP
• Oracle ERP
• Informatica MDM
• Data Warehouse

Initially, direct integrations existed between systems. As the number of systems grew, maintaining interfaces became difficult.

We introduced MuleSoft as a centralized integration hub, reducing integration complexity and simplifying monitoring.

Architect Perspective

Hub-and-Spoke works well for enterprise organizations with multiple applications.

However, architects must avoid turning the hub into a bottleneck by designing scalable APIs and event-driven communication patterns.

Q8. How do you design loosely coupled integrations?

Answer

A loosely coupled system is a system whose components or services interact with each other with minimal dependencies. Each part can often be modified, replaced, scaled, or fail independently without significantly affecting the rest of the system.

Principles of Loose Coupling

1. Avoid Direct Database Access

Systems should communicate through APIs or events rather than reading each other’s databases.

2. Use Events Instead of Direct Calls

Publishing events reduces dependency between systems.

3. Introduce Middleware

Middleware abstracts backend systems from Salesforce.

4. Use Canonical Data Models

Canonical Data Model (CDM) is a pattern used in enterprise integration to establish a single, standardized data format. Standardized data structures simplify transformations and integrations.

Example

Instead of:

• Salesforce → SAP
• Salesforce → ERP
• Salesforce → Data Warehouse

Salesforce publishes:

“Customer Created” Event and Subscribers

• SAP
• ERP
• Data Warehouse

Each system independently processes the event.

Benefits

• Independent deployments
• Better scalability
• Improved resilience
• Simplified maintenance

Architect Perspective

One common mistake is creating tightly coupled synchronous integrations because they seem easier initially.

As organizations scale, tightly coupled architectures become difficult and expensive to maintain.

Q9. What are common integration challenges in enterprise Salesforce implementations?

Answer

Enterprise integrations typically face technical, operational, and business challenges.

Common Challenges

1. API Limits

Salesforce enforces daily API consumption limits.

Example

A large customer synchronization process can easily consume millions of API calls if poorly designed.

2. Data Quality Issues

Inconsistent data structures often create integration failures.

Example

SAP stores customer IDs differently than Salesforce.

Data mapping and validation become critical.

3. Latency Requirements

Some processes require sub-second responses while others tolerate delays.

Example

Payment authorization requires immediate response.

Nightly reporting does not.

4. Error Handling

Temporary failures can cause data inconsistencies.

Example

SAP outage during order processing.

Without retries and message queues, transactions may be lost.

5. Security and Compliance

Healthcare and financial institutions often require:

• Encryption
• Audit Trails
• Mutual TLS
• Token Management

6. Scalability

Architectures that work for thousands of records often fail at millions of records.

Architect Perspective

The most successful integrations are designed around failure.

Instead of assuming systems will always be available, architects should design for:

• Retries
• Monitoring
• Recovery
• Replay
• Disaster Scenarios

Q10. What role does middleware play in Salesforce integrations?

Answer

Middleware acts as an intermediary layer between Salesforce and external systems. It takes input from the source system and then calls the target system with the required input.

Examples:

• MuleSoft
• Dell Boomi
• Informatica
• Azure Integration Services

Responsibilities of Middleware

1. Protocol Transformation

Example:

• Salesforce sends REST JSON.
• Legacy ERP requires SOAP XML.
• Middleware performs the transformation.

2. Data Transformation

Example:

Salesforce Account becomes the SAP Customer Master Record with different field structures.

3. Routing

Middleware determines which systems should receive data.

Example:

Customer Created Event

sent to:

• SAP
• Data Warehouse
• Marketing Cloud

4. Security

Middleware can centralize:

• Authentication
• Authorization
• Token Management
• Audit Logging

5. Monitoring

Middleware provides:

• Error Dashboards
• Transaction Tracking
• Retry Management

Real Project Example

A manufacturing client integrated Salesforce with:

• SAP
• Oracle ERP
• ServiceNow
• Snowflake

Without middleware, Salesforce required separate integrations for each system.

By implementing MuleSoft:

• Integrations became reusable
• Monitoring improved
• Development time decreased
• Security became centralized

Architect Perspective

• Middleware should not be introduced simply because it exists.
• For two simple systems, direct integration may be sufficient.
• As system complexity grows, middleware becomes increasingly valuable for maintainability and scalability.

Q11. What Salesforce APIs have you used, and when would you choose each one?

Answer

Salesforce provides multiple APIs designed for different integration needs. These APIs provide programmatic access to external systems.

1. REST API

REST API (Representational State Transfer Application Programming Interface) is an architectural style that allows different systems to communicate with each other over the internet. It is best for lightweight CRUD operations.

Example

Mobile application retrieving customer details.

2. SOAP API

A SOAP (Simple Object Access Protocol) API is a formalized, highly secure messaging protocol used to exchange structured data between systems. Best for enterprise systems requiring strict contracts.

Example

Legacy ERP integration using WSDL-based communication.

3. Bulk API 2.0

Bulk API 2.0 provides a simple interface to load large amounts of data into your Salesforce org and to perform bulk queries on your org data. Best for large-scale data processing.

Example

Loading 20 million customer records during migration.

4. Composite API

A Composite API bundles multiple sequential API requests into a single API call. This is best for reducing API calls.

Example

Creating:

• Account
• Contact
• Opportunity

within a single request.

5. GraphQL API

GraphQL is a query language for fetching required data using an API. It allows clients to request precise data from the server, making it more efficient and flexible compared to traditional REST APIs.

Example

Customer portal requesting specific fields from multiple objects.

6. Streaming API

A Streaming API is like a live broadcast that sends a request and waits for a response. Connections are kept open so the server can keep sending updates as soon as they happen. It is best for real-time notifications.

Example

Live dashboard updates.

7. Metadata API

Salesforce Metadata API lets us retrieve, deploy, create, update, and delete the org’s metadata like object, field or page layout changes. 

Example

CI/CD pipelines using SFDX.

8. Tooling API

Salesforce Tooling API is designed to provide fine-grained, high-performance access to an organization’s metadata. It is best for development and code analysis.

Example

Automated code quality tools.

9. Pub/Sub API

Pub Sub API creates a single endpoint to securely query, update, or publish data. It is best for modern event-driven architectures.

Example

Integrating Salesforce events with Kafka consumers.

Architect Perspective

Choosing the correct API is critical. Many organizations misuse REST API for large data loads when Bulk API would provide significantly better performance and scalability.

Q12. REST API vs SOAP API: When would you use one over the other?

Answer

REST and SOAP are two of the most commonly used APIs in Salesforce integrations. The choice depends on business requirements, performance considerations, and external system capabilities.

REST API

REST is lightweight and uses JSON payloads.

Advantages

• Easy to consume
• Faster development
• Smaller payload size
• Better support for web and mobile applications

Example

• A React application displays customer information from Salesforce.
• The application uses REST APIs to retrieve Accounts, Contacts, and Opportunities.
• JSON responses make integration straightforward.

SOAP API

SOAP uses XML and WSDL contracts.

Advantages

• Strongly typed contracts
• Formal schema validation
• Enterprise system compatibility
• Better support for legacy systems

Example

A banking system built years ago requires WSDL-based integrations and strict message validation. SOAP API is often the preferred choice in this use case.

Real Project Example

In a healthcare project:

• Mobile applications used REST APIs.
• Legacy policy administration systems used SOAP APIs.

Both APIs coexisted based on the needs of each consumer.

Architect Perspective

Choose REST whenever possible for modern integrations.

Choose SOAP when:

• External systems require WSDL contracts.
• Regulatory requirements demand strict schema validation.
• Legacy enterprise systems mandate SOAP communication

Q13. What are the advantages of Composite API?

Answer

Composite API allows multiple operations to be executed through a single API request.

Example

Without Composite API:

Create:

• Account
• Contact
• Opportunity

Requires three separate API calls.

With Composite API:

All records can be created in one request.

Benefits

1. Reduced API Consumption: Fewer API calls are made. So it will reduce API consumption.
2. Improved Performance: It will reduce network latency.
3. Transactional Processing: Multiple operations can be chained together.
4. Simplified Integration Logic: External systems manage fewer requests.

Real Project Example

A customer onboarding application needed to create:

• Account
• Contact
• Opportunity
• Case

Using Composite API reduced API calls by over 70%.

Architect Perspective

Composite API is ideal when:

• Related records are created together.
• API limits are a concern.
• Network latency should be minimized.

Avoid Composite API for extremely large data volumes where Bulk API is more appropriate.

Q14. What is Bulk API 2.0 and when should it be used?

Answer

Bulk API 2.0 is Salesforce’s asynchronous API designed for processing large data volumes.

Common Use Cases

• Data migration
• Master data synchronization
• Historical data loading
• Enterprise ETL processes

Example

A company acquires another business and must migrate:

• 15 million Accounts
• 50 million Contacts

Using REST API would take an excessive amount of time and consume significant API limits.

Bulk API 2.0 processes the records asynchronously and much more efficiently.

Benefits

• Handles Massive Data Volumes – Millions of records can be processed.
• Better Performance as it is optimized for large datasets.
• Reduced Complexity – Salesforce automatically manages batch sizing.
• Asynchronous Processing – No need to wait for immediate responses.

Real Project Example

A retail client migrated:

• 30 million customer records
• 100 million transaction records

Bulk API 2.0 significantly reduced migration time compared to traditional APIs.

Architect Perspective

A common interview mistake is proposing REST APIs for large-scale migrations.

As an architect, always consider:

• Volume
• Throughput
• API consumption

For large datasets, Bulk API should be the default choice.

Q15. How does GraphQL API differ from REST API?

Answer

GraphQL allows consumers to request exactly the data they need. REST returns predefined resources.

REST Example

To display an Account dashboard, an application might need:

• Account
• Contacts
• Opportunities

Multiple REST requests may be required.

GraphQL Example

A single GraphQL query can retrieve:

• Account Name
• Contacts
• Open Opportunities

in one request.

Benefits

• Reduced Overfetching – Only required fields are returned.
• Reduced Underfetching – Multiple datasets can be retrieved together.
• Better Performance – Fewer network requests.
• Flexible Client Queries – Consumers control response structure.

Real Project Example

An Experience Cloud portal displayed customer information from multiple objects. GraphQL reduced API calls and improved page load times.

Architect Perspective

GraphQL is particularly useful for:

• Mobile applications
• Customer portals
• User interfaces requiring multiple related datasets

REST remains simpler for traditional CRUD integrations.

Q16. What is Pub/Sub API and how does it differ from Streaming API?

Answer

Both APIs support event-driven architectures, but they serve different purposes.

Streaming API

A Streaming API is like a live broadcast that sends a request and waits for a response. Connections are kept open so the server can keep sending updates as soon as they happen. It is best for real-time notifications. This API is based on CometD.

Supports:

• PushTopic Events
• Platform Events
• Change Data Capture

Primarily designed for event notifications.

Pub/Sub API

Pub Sub API creates a single endpoint to securely query, update, or publish data.

Provides:

• Higher performance
• Bi-directional communication
• Better scalability
• Efficient event consumption

Example

A financial services organization processes thousands of customer updates every minute.

Pub/Sub API provides better performance and throughput compared to traditional Streaming API implementations.

Architect Perspective

• For modern enterprise event-driven architectures: Prefer Pub/Sub API.
• For existing implementations already using CometD: Streaming API may still be appropriate.

Q17. What are Salesforce API limits and how do they impact integration design?

Answer

Salesforce enforces API consumption limits to protect platform resources. It will protect multi-tenant platform infrastructure and ensure fair resource allocation for all organizations.

Common Limits

• Daily API requests
• Concurrent requests
• Event delivery limits
• Platform Event limits

Example

A customer integration executes:

• 500,000 API calls daily

As business volume grows, API limits may become a bottleneck.

Design Considerations

1. Reduce API Calls– Use Composite API to reduce API calls.
2. Process Large Volumes Efficiently– Use Bulk API to upload large files.
3. Avoid Excessive Polling – Use Platform Events or CDC instead of updating data frequently
4. Implement Caching – Avoid repetitive requests that will fetch the same data. Instead use platform caching.

Real Project Example

• A customer synchronised every Account hourly. This generated millions of unnecessary API calls.
• We redesigned the solution using CDC and reduced API consumption dramatically.

Architect Perspective

• API limits should influence architecture decisions from day one.
• Ignoring limits often results in expensive redesigns later.

Q18. How do you monitor API consumption in Salesforce?

Answer

Monitoring API usage is essential for identifying bottlenecks before they impact business processes.

Monitoring Options

• System Overview- Provides current API usage.
• Event Monitoring – provides detailed API activity.
• Setup Monitoring – Tracks API request volumes.
• External Monitoring Tools- Examples: Splunk, Datadog, New Relic

Example

An integration team notices increasing API usage each month.

Monitoring reveals:

A scheduled job unnecessarily synchronises unchanged records. The process is optimized using delta synchronization.

Architect Perspective

Monitoring should not be an afterthought. Every enterprise integration should include:

• Dashboards
• Alerts
• Usage trends
• Capacity planning

Q19. What strategies help reduce API consumption?

Answer

Reducing API usage improves scalability and lowers the risk of hitting limits.

Strategy 1: Composite API

Combine multiple operations into one request.

Strategy 2: Bulk API

Process large datasets efficiently.

Strategy 3: Change Data Capture

Publish only changed records.

Strategy 4: Platform Events

Replace polling with event-driven communication.

Strategy 5: Caching

Store frequently accessed data.

Example

An ERP system queried Salesforce every 5 minutes. We replaced polling with CDC.

Result:

• Reduced API consumption
• Improved latency
• Simplified architecture

Architect Perspective

The best API call is often the one that never happens. Architects should always look for opportunities to eliminate unnecessary requests