Salesforce and Microservices

The Question Every CTO Eventually Asks

The conversation happens in almost every large enterprise Salesforce programme. An architect who has spent years building microservices in AWS or Azure joins the programme and asks: "Where does Salesforce fit in our service mesh?" The honest answer is that Salesforce doesn't fit in a service mesh — it's a different kind of system, and forcing the microservices mental model onto it creates problems that wouldn't exist with a clearer architectural understanding.

Salesforce is not a microservice. It's a system of record and engagement for customer data — a packaged application with its own data model, business logic execution environment, and API surface. Microservices are independent, deployable units of business logic with their own data stores. The two can coexist extremely effectively, but the relationship is one of integration, not equivalence.

Where Salesforce Fits in a Microservices Architecture

In a well-designed enterprise architecture, Salesforce occupies a specific role: it is the system of record for customer, account, opportunity, case, and related CRM data. It is the engagement layer for sales, service, and marketing workflows. It exposes this data and these workflows via APIs. It consumes data and events from external systems via those same APIs and event mechanisms.

What Salesforce is not: it is not the right place to run complex computation (Governor Limits constrain this), it is not the right place for high-frequency transactional processing (API rate limits and governor limits constrain this), and it is not a general-purpose application platform for all business logic.

The Service Boundary Question

The most important architectural decision in a Salesforce + microservices architecture is where the service boundary lies. Business logic that directly involves CRM data belongs in Salesforce. Opportunity scoring based on CRM fields, case routing based on account SLA, contact deduplication — these belong in Salesforce because that's where the data lives and where the business context exists.

Business logic that involves multiple external systems, heavy computation, or non-CRM data belongs in microservices. Credit scoring, pricing calculation from a complex rules engine, order management that spans ERP and CRM, machine learning inference — these belong externally, with results surfaced in Salesforce via API or events.

Integration Patterns That Work at Scale

There are four primary integration patterns for Salesforce in a microservices architecture, each appropriate for different data flow characteristics.

Pattern 1: Synchronous REST/SOAP (Request-Response)

Salesforce calls an external microservice via a Named Credential and Apex HTTP callout, waits for the response, and uses the result in the same transaction. Appropriate for: real-time data lookups, address validation, real-time pricing. Constraint: the callout timeout is 120 seconds maximum, and the callout consumes the transaction's Governor Limit budget. Not appropriate for high-latency or unreliable external services.

Pattern 2: Async via Platform Events (Salesforce → External)

Salesforce publishes a Platform Event when something happens in the CRM. External microservices subscribe via the Streaming API or a message queue bridge. No tight coupling — the external service processes the event independently. Appropriate for: notifications, data replication to external systems, triggering downstream workflows without waiting for results.

Pattern 3: Change Data Capture (CRM data replication)

CDC automatically publishes events for every create/update/delete on Salesforce records. External systems subscribe and maintain their own copy of relevant Salesforce data. Appropriate for: data warehouses consuming CRM data, search indexes, analytics platforms, microservices that need CRM data locally for performance.

// Subscribing to Salesforce Change Data Capture events via EmpConnector (Java)
// CDC events are published to /data/AccountChangeEvent channel

EmpConnector connector = new EmpConnector(bayeuxParameters);
connector.start().get(30, TimeUnit.SECONDS);

// Subscribe to Account CDC events
connector.subscribe("/data/AccountChangeEvent", -1L, event -> {
    // event contains: changeType (CREATE/UPDATE/DELETE),
    // changedFields, recordIds, header.commitTimestamp
    String changeType = (String) ((Map) event.get("payload"))
        .get("ChangeEventHeader");
    processAccountChange(event);
    return null;
});

// CDC provides 72 hours of replay by default — use replayId = -1
// for all new events, or a specific replayId for replay from a point

Pattern 4: External Service → Salesforce (Inbound)

External microservices write to Salesforce via REST API, Bulk API, or Platform Event publishing. Appropriate for: order status updates from ERP, fulfilment events from logistics, account data from MDM. Rate limits apply — plan for 15,000 REST API calls per day (Enterprise Edition default) and use Bulk API 2.0 for high-volume batch updates.

Event-Driven Architecture: CDC, Platform Events, and Streaming

Event-driven integration between Salesforce and microservices is architecturally superior to point-to-point synchronous calls for most CRM workflows. The key mechanisms:

Platform Events are custom event objects you define. Salesforce code publishes them; external systems subscribe. They support up to 250,000 events per day (Enterprise Edition) and retain events for 72 hours for replay. Platform Events are the right choice when you need to define the event schema explicitly and control exactly what data is shared.

Change Data Capture is Salesforce-managed, automatically publishing events for all record changes. CDC is the right choice when external systems need to track all changes to specific objects without requiring custom event publishing logic in Salesforce.

Heroku and the Salesforce PaaS Option

Heroku is Salesforce's owned PaaS, and for microservices that need to integrate closely with Salesforce, it has a genuine architectural advantage: Heroku Connect provides bi-directional data sync between Heroku Postgres and Salesforce objects with sub-minute latency, without consuming Salesforce API limits.

For microservices that primarily read and write CRM data (pricing engines that query Account and Product data, document generation services, reporting aggregation services), Heroku with Heroku Connect can be more efficient than REST API integration — the microservice reads from a local Postgres replica rather than calling Salesforce APIs for each request.

The architectural trade-off: Heroku is more expensive than AWS/GCP/Azure for general compute, and it doesn't benefit from the broader cloud ecosystem (managed Kubernetes, AI services, etc.) that hyperscalers offer. Use Heroku when the Heroku Connect data sync advantage is significant. Use other cloud platforms when compute or ecosystem matters more than native Salesforce proximity.

Anti-Patterns: When Microservices Break Salesforce

Several anti-patterns appear repeatedly in enterprise programmes that have tried to integrate microservices with Salesforce without a clear architectural framework.

Anti-pattern: Bypassing Salesforce logic via direct database access. Some architects, frustrated with API rate limits, explore direct Oracle database access to Salesforce's underlying tables. Salesforce explicitly prohibits and technically prevents this — it's not just a terms violation, it's architecturally impossible from outside Salesforce's infrastructure. The correct response to API limit constraints is to optimise integration patterns (batch vs real-time, CDC vs REST), not to attempt platform circumvention.

Anti-pattern: Using Salesforce as an event bus. Platform Events are not a general-purpose message queue. Using Salesforce to route events between external microservices — where the event has nothing to do with CRM data — consumes Platform Event limits unnecessarily and creates a coupling to Salesforce that isn't justified by the use case. Use a real message broker for inter-microservice events.

Anti-pattern: Synchronous callouts in triggers. Apex triggers that make synchronous callouts to external microservices are a Governor Limit antipattern — callouts are not allowed in trigger contexts that might be called in bulk. The correct pattern: trigger publishes a Platform Event, and a subscriber (Apex trigger subscriber or external service) makes the callout asynchronously.

Salesforce as System of Record vs System of Engagement

The cleanest microservices + Salesforce architectures have a clear model: Salesforce is either the system of record for customer data (the canonical source that external systems sync from) or the system of engagement (the UI and workflow layer that sits on top of data stored elsewhere). These roles have different integration implications.

In a system of record model: Salesforce holds the master customer data. External systems subscribe to CDC to keep their own copies. Writes go to Salesforce first and propagate out. MDM conflicts are resolved in Salesforce. This model works well when CRM data quality and completeness is the priority.

In a system of engagement model: Salesforce is the UI and workflow layer. Master data lives in an external MDM or data warehouse. Salesforce reads data via Salesforce Connect (OData adapter) or replicates a subset via batch jobs. The integration complexity is higher, but this model works well when data governance requires a non-Salesforce system of record.