Event‑Driven Architecture in Salesforce Integrations

Enterprise systems often begin their integration journey with synchronous APIs, scheduled batch jobs and custom scripts. These patterns work for many use cases, but they create tight coupling and latency between systems. As business processes become distributed across multiple applications, organisations need integrations that can react in near real time, scale horizontally and minimize dependencies. Event-Driven Architecture (EDA) addresses this need by turning state changes into events that other systems can consume. Rather than calling another system directly, an application publishes an event to an event bus. Subscribers consume those events and react independently.

Salesforce provides a rich set of tools, Platform Events, Change Data Capture (CDC), Streaming API and Pub/Sub API, that support event-driven integration patterns. Understanding how to combine these tools with architectural patterns is essential when you work as a Salesforce consulting partner or lead integration projects as a senior developer. This article demystifies the concepts behind event-driven integrations, outlines the available Salesforce capabilities and shows how to design robust, scalable solutions.

What Is Event-Driven Architecture?

Event-Driven Architecture is an integration model built around the publication and consumption of events, which represent meaningful changes in a business process. Instead of coupling applications through direct service calls, systems send events to an event broker and consumers subscribe to the events they care about. According to SAP’s explanation of EDA, an event is any action or state change important to a business, such as a transaction, abandoned shopping cart or sensor reading. When an event occurs, a message is automatically sent to all systems that need to respond, enabling near-real-time interactions. Event-driven architectures are inherently decoupled; producers do not need to know about consumers, and consumers can subscribe or unsubscribe without changing the producer.

Two primary patterns govern how events flow through a system: publish/subscribe and event streaming. With pub/sub, consumers subscribe to specific channels and receive events as soon as they are published. Events are transient once consumed, they disappear from the broker. Event streaming, by contrast, retains events for later consumption; consumers can replay events from any point in the stream. This retention capability is vital for event-driven data pipelines and auditing scenarios.

In an EDA, applications act as event producers or event consumers (or both). Producers capture or generate events and publish them to the broker. Consumers process events, trigger workflows or generate new events. Most enterprise implementations rely on a broker (message bus) to manage the distribution, retention and sequencing of events. Brokers decouple producers and consumers, provide reliability and scale, and offer features like replay and delivery guarantees.

Why Event-Driven Architecture Matters in Salesforce Integrations

Traditional Salesforce integration approaches rely on synchronous REST or SOAP APIs, scheduled ETL jobs and middleware polling. While these patterns have served customers well, they have inherent limitations:

Latency and Dependency: Synchronous APIs tie the consumer’s response time to the producer’s availability. A slow or unavailable external system can block a Salesforce transaction and degrade user experience.

Limited Scalability: Polling or batch jobs generate load on both Salesforce and the target system. As transaction volumes grow, scaling these integrations becomes complex and costly.

Tight Coupling: API-based integrations create dependencies between systems. Changing one system often requires changes in others, increasing technical debt and reducing agility.

Event-driven integration addresses these issues. Events enable asynchronous communication: producers publish an event and return immediately, without waiting for consumers to process it. Consumers subscribe to the event and react in their own context, enabling loose coupling and horizontal scalability. Because events carry state changes, they allow multiple downstream systems, analytics, ERP, mobile apps to react in real time. This pattern improves responsiveness and supports modern microservices architectures.

Salesforce’s event infrastructure builds on these principles. Platform Events and Change Data Capture allow Salesforce to publish events when records change, while Streaming API and Pub/Sub API deliver events to external subscribers. By combining these tools, architects can build loosely coupled integrations that propagate changes across systems with minimal latency.

Salesforce Event Infrastructure

Salesforce provides several native capabilities to implement an EDA. This section examines Platform Events, Change Data Capture, Streaming API, Pub/Sub API and Event Relays. These tools form the foundation for event driven API management, event-driven data architectures and real-time data pipelines.

Platform Events

Platform Events are custom event types defined in Salesforce. They behave like standard Salesforce objects, but they represent messages on the event bus rather than data records. Platform Events simplify the process of communicating changes: applications publish events and any number of subscribers can listen and respond. Since events are not persisted in standard tables, they do not affect storage limits.

Platform Events are ideal when Salesforce acts as the event producer or consumer. For example, a business process might publish an event when an Opportunity closes. Downstream systems, such as an ERP or a billing platform subscribe to the Salesforce event planning channel and trigger their own workflows. External applications subscribe through CometD, the gRPC-based Pub/Sub API or third-party connectors. Internally, Lightning Web Components, flows and Apex triggers can subscribe to the same event. Platform Event–triggered flows allow administrators to declaratively define listener logic; when an event is published, the flow starts automatically.

Publishing and Subscribing

To publish Platform Events, developers can use Apex (via EventBus.publish), REST or SOAP API operations, Bulk API or Flow. When an external app publishes an event, it authenticates via OAuth, JWT or a session token and calls the Pub/Sub API or the REST API. Subscribers use CometD clients (often implemented with EMP Connector) or the Pub/Sub API to receive events. Platform Events support replay; subscribers can replay missed events using the event’s replay ID, enabling resilient consumption.

Use Cases

Platform Events fit scenarios where Salesforce initiates real-time notifications and multiple systems need to react. Examples include: notifying downstream systems of closed deals, triggering marketing automation when a customer onboards, integrating IoT devices that report status back into Salesforce and orchestrating business processes across multiple microservices. Because Platform Events are defined declaratively, they enable non-developers to configure event channels and listeners, making them a powerful tool in organisations that follow a Salesforce integration partner model.

Change Data Capture (CDC)

Change Data Capture publishes events when Salesforce records are created, updated, deleted or undeleted. CDC is declarative: administrators enable CDC on specific objects, and Salesforce automatically generates change events. Each change event includes details about the changed fields, the type of operation and metadata such as the record ID. Event consumers subscribe via the Pub/Sub API or Apex triggers. Because CDC messages include the changed fields, downstream systems can update their own copies without making additional API calls.

CDC is useful for keeping external systems in sync with Salesforce. For example, an integration service can subscribe to Customer__c change events, update an ERP system and maintain a near-real-time replica of Salesforce data. Since CDC is an out-of-the-box feature, it requires no Apex code, making it accessible to administrators and developers alike.

Streaming API and Pub/Sub API

Streaming API is Salesforce’s original event streaming mechanism. It supports PushTopic events, Generic events, Platform Events and Change Data Capture events. Clients use the Bayeux protocol (CometD) to subscribe to channels. While functional, Streaming API imposes limitations on throughput and data formats. The newer Pub/Sub API builds on gRPC and HTTP/2 to deliver binary event messages (in Apache Avro format) and offers higher performance. It provides a unified interface to publish and subscribe to Platform Events, CDC events and Real-Time Event Monitoring events.

Pub/Sub API is the recommended choice for external event consumers. It supports authentication via OAuth, JWT or session tokens and allows both publishing and subscribing. Its efficiency makes it suitable for high-throughput scenarios and event-driven data pipelines.

Event Relays

Event Relays connect Salesforce’s event bus to external event brokers, such as Amazon EventBridge. An event relay streams Platform Events or CDC events to the external broker, enabling integration with cloud services, serverless functions and third-party applications. This pattern is particularly useful when enterprise architectures incorporate multiple event brokers or when a microservices platform uses an external message bus. Salesforce provides Event Relay capabilities (currently only for AWS EventBridge) to send events without building a custom connector. Architects can also implement custom relays using Pub/Sub API and connectors like Apache Kafka, MuleSoft or Azure Event Grid.

Event-Driven Integration Patterns

Event-driven architecture can be applied using several integration patterns. Selecting the right pattern depends on the complexity of the system, required responsiveness and data flow characteristics. As a senior Salesforce developer or consultant, you should evaluate each pattern based on the business context and technical constraints.

Event Notification Pattern

In the event notification pattern, events contain only enough information to identify the record or process that changed. The consumer receives the notification and then calls an API to retrieve the full state. This pattern minimizes event payloads, reduces message size and keeps the event bus efficient. For example, when an Opportunity status changes to Closed Won, Salesforce publishes an OpportunityClosed__e event with the Opportunity ID. The ERP system receives the event, fetches the full Opportunity details using a REST API, then creates an order. This pattern is suitable for integrations where the consumer has reliable API access to Salesforce and where additional data retrieval is acceptable.

Event-Carried State Transfer Pattern

In this pattern, the event contains the full data needed by the consumer. Events are “self-contained” so that consumers do not need to make subsequent API calls. For instance, a OrderCreated__e event might include the product list, quantities, pricing and customer information. Downstream systems consume the event and update their own records accordingly. Event-carried state transfer reduces API calls but can increase event payload sizes. Architects must balance payload size and network efficiency with the convenience of self-contained data. In Salesforce, CDC events are often used for this pattern because they include changed fields.

Event Streaming Pattern

Event streaming patterns involve continuous streams of events, where consumers can replay events and process them over time. This pattern is particularly useful for analytics and data pipelines, where historical data is processed, aggregated or analysed. For example, a data analytics platform might subscribe to CDC events for all Account changes and build a time-series profile of customer value. Because events are retained in the stream, consumers can process them multiple times, implement complex event processing or recover from failures. When implementing event streaming, consider event retention periods, replay limits and consumer lag.

Passed Messages and Fanout Patterns

Additional patterns include passed messages and fanouts. In a passed-message pattern, each subscriber receives a unique copy of the event, enabling concurrent processing with independent acknowledgement. The fanout pattern delivers a single message to multiple subscribers through a shared queue; all subscribers read from the same queue. Fanout improves performance but makes it harder to verify that each subscriber processed the message. These patterns might be implemented using MuleSoft, third-party message brokers or Salesforce queues, depending on the integration landscape.

Event-Driven API Management

As organisations adopt microservices and API-led architectures, event-driven principles must be integrated into API management. Event driven API management involves designing APIs that publish events when state changes occur and subscribe to events to trigger actions. For example, an API that creates orders could also publish an OrderCreated event. API gateways and management tools must support asynchronous protocols (e.g., WebSockets, MQTT, gRPC) in addition to REST. In Salesforce, the Pub/Sub API functions as an event-driven API layer, enabling clients to publish and subscribe using the same authentication and governance policies that apply to REST or SOAP. Architectural decisions include choosing appropriate protocols, defining event schemas, versioning and ensuring security across event channels.

Event-Driven Architecture vs API-Based Integrations

It’s important to understand when to use event-driven patterns and when synchronous APIs are preferable. Both patterns often coexist in a hybrid architecture.

When API-Based Integrations Make Sense

Immediate Response Needed: When the caller must receive a response before proceeding, for example, validating a payment before confirming an order, synchronous APIs are appropriate.

Transactional Consistency: If an operation requires strict transaction boundaries (e.g., complex financial updates), synchronous calls with rollback capabilities may be necessary.

Simple CRUD Operations: For basic create/read/update/delete operations where the consumer is the only system affected, a direct API call is often simpler.

When Event-Driven Patterns Excel

Multiple Consumers: When multiple systems need to react to the same change (e.g., analytics, notifications, ERP updates), events decouple the producer from each consumer.

Loose Coupling Required: In large enterprises, systems change at different rates. Events minimize dependencies, making evolution easier.

High Throughput and Scalability: Event brokers handle high volumes of events and allow horizontal scaling of consumers.

Event-Driven Data Architecture: When building real-time data pipelines and analytics, events provide a consistent, chronological stream of state changes.

Most enterprises adopt a hybrid approach: use APIs for transactional operations and UI-driven flows, and events for asynchronous, scalable and multi-consumer workloads. For example, a payment service might synchronously validate a credit card but also publish a PaymentProcessed event to trigger shipping and analytics.

Event-Driven Data Architecture and Pipelines

Data architectures are evolving from batch-oriented ETL processes to real-time streams. An event driven data architecture uses events as the fundamental unit of data change. Instead of periodically extracting data, systems publish events whenever records change. Downstream consumers, data warehouses, data lakes, AI models subscribe to the events and update their datasets incrementally. This approach reduces latency, improves data freshness and supports streaming analytics.

One common pattern is the event driven data pipeline. Here, CDC events flow into an event broker (such as Kafka or AWS EventBridge) and then into a processing engine like Apache Flink, Spark Structured Streaming or Salesforce’s Einstein Analytics connectors. The processing engine transforms and enriches the data, then writes it to a target store. Because events carry only the changed fields, these pipelines are efficient and maintain data consistency. With Salesforce, CDC and Platform Events serve as the first step of the pipeline, feeding data into external analytics or AI services. Architects must consider event ordering, exactly-once processing, schema evolution and backpressure to ensure reliable pipelines.

Integration Governance for Event-Driven Architectures

Without proper governance, event-driven systems can become chaotic. Governance ensures that events are well defined, consumers know what to expect and the event bus operates reliably. Key governance considerations include:

Event Naming Conventions

Consistent naming helps developers and integrators understand the purpose of an event. Use clear, descriptive names that follow a hierarchical format, such as Order.Created, Customer.AccountUpdated or Case.Escalated. Include version numbers if the schema is likely to change (e.g., Order.Created.v2). This convention aids discoverability and documentation.

Payload Design and Schema Management

Events should contain only the data required by consumers. Excessive payloads increase network overhead and complicate data governance. Use schema registries (like AWS Glue Schema Registry or Confluent Schema Registry) to manage event schemas, enforce compatibility and document field meanings. For Salesforce events, define Platform Event or CDC fields thoughtfully, and consider using ChangeEventHeader fields to include metadata such as the commit number or sequence number.

Event Versioning

When event structures change, versioning strategies prevent breaking existing consumers. You can version the event name (e.g., Order.Created.v1 to Order.Created.v2) or use a schema registry that supports schema evolution. In Salesforce, you can create new Platform Event definitions or additional CDC fields to introduce new fields without disrupting subscribers. Document changes and communicate them through release notes.

Event Monitoring and Observability

Monitoring event flows is crucial. Metrics to track include publish rates, subscriber lag and processing failures. Salesforce provides Event Monitoring logs that can be streamed and analysed, while external brokers offer metrics and dashboards. Implement dead-letter queues for failed events and alerting mechanisms for backlogs. Observability tools should allow tracing an event from production to consumption, mapping dependencies and highlighting failures. Without observability, debugging distributed event flows becomes challenging.

Common Use Cases for Event-Driven Salesforce Integrations

Several scenarios benefit strongly from event-driven patterns:

Customer Lifecycle Automation

When a new customer signs up, multiple systems must respond: CRM to create the account, marketing automation to send welcome emails, billing to set up invoices and analytics to record the event. Publishing a CustomerOnboarded Platform Event allows these systems to subscribe and execute their workflows independently.

Order Processing and Fulfilment

An e-commerce platform integrated with Salesforce may publish OrderPlaced events. ERP systems consume the event to allocate inventory and generate shipping labels, while marketing systems update customer loyalty points. When the order ships, the ERP publishes an OrderShipped event that triggers status updates in Salesforce and notifications to the customer.

Financial System Synchronisation

Financial institutions require accurate, real-time data across accounting, CRM and risk systems. CDC events allow changes to Account, Opportunity or custom financial objects to be streamed into accounting software. Conversely, external systems can publish events that Salesforce consumes to update records.

Real-Time Analytics and AI

Streaming CDC events into a data lake or data warehouse enables up-to-date analytics dashboards. AI models can subscribe to events, perform inference (e.g., churn prediction) and publish results back into Salesforce. For example, a UsageSpike event might trigger an AI model to predict customer churn and create a task for a sales rep.

IoT and Device Integrations

Connected devices send telemetry data as events. Salesforce Platform Events or Event Relays forward these events to IoT platforms, where they trigger maintenance workflows, alarms or usage tracking. For instance, a smart printer can publish a LowInk event that initiates an automatic reorder process.

Salesforce Event Relay Use Cases

Event Relays are used to integrate Salesforce’s event bus with external brokers like AWS EventBridge. Use cases include serverless pipelines, cross-platform microservices and integration with cloud services such as AWS Lambda, Azure Functions or Google Cloud Functions. Relays allow events originating in Salesforce to trigger serverless functions, orchestrate workflows in other systems and feed centralized event buses.

Implementation Considerations

Implementing event-driven integrations requires careful planning. Consider the following technical aspects:

Limits and Quotas

Salesforce imposes limits on Platform Event publish rates, subscription limits and message retention periods. For high-volume scenarios, evaluate limits on the number of platform events per hour and the maximum event payload size. CDC messages are retained for 72 hours by default. Use replay capabilities or external brokers to handle long-term retention.

Ordering and Idempotency

Event ordering is crucial in certain workflows. While Platform Events preserve the order of events per producer, cross-object ordering is not guaranteed. Consumers must implement idempotent processing to handle duplicate or out-of-order events. Include sequence numbers or timestamps in event payloads to help consumers detect duplicates and reorder events if necessary.

Error Handling and Retry Strategies

Because events are asynchronous, producers do not know whether a consumer processed the event successfully. External consumers should implement retry logic and track message offsets or replay IDs. Salesforce provides limited retry capabilities for Outbound Messages, but Platform Events are delivered only once. Middleware such as MuleSoft or Kafka can provide dead-letter queues and retry policies.

Security and Access Control

Events may contain sensitive data. Define appropriate permissions for publishing and subscribing. Use OAuth scopes or JWT claims to grant event access. In Salesforce, event delivery honours record-level security for CDC events and field-level security for Platform Events. Event Relays require additional configuration to manage credentials and access controls in external brokers.

Tooling and Middleware

Selecting the right tooling depends on the integration landscape. MuleSoft, Kafka, RabbitMQ, AWS EventBridge, and Azure Event Grid are popular choices. Salesforce’s Pub/Sub API and Event Relays provide direct integration. Evaluate factors such as latency requirements, protocol support, scalability and existing investments. If you are delivering Salesforce implementation services, ensure that the chosen middleware aligns with client architecture and skillsets.

Summary

Event-Driven Architecture enables Salesforce integrations that are responsive, scalable and loosely coupled. By converting state changes into events and distributing them through an event bus, systems can react in near real time without being tightly bound together. Salesforce’s native capabilities, Platform Events, Change Data Capture, Streaming API, Pub/Sub API and Event Relays, provide the building blocks for event-driven integrations. The publish/subscribe pattern decouples producers and consumers, while event streaming retains events for later processing. Platform Events allow apps to communicate via custom event messages, whereas CDC automatically publishes record changes. Pub/Sub API offers a unified interface for publishing and subscribing.

Choosing between API-based and event-driven patterns depends on the integration’s requirements. Synchronous APIs remain appropriate for operations requiring immediate responses and strict transactional boundaries, while Event-Driven Architecture excels when multiple systems need to react asynchronously, when scalability matters, or when building event-driven data pipelines. Governance practices, consistent naming, payload design, versioning and observability, ensure event-driven integrations remain maintainable. With thoughtful implementation and the right tools, event-driven patterns can modernize Salesforce integrations, reduce latency and provide the backbone for real-time, data-driven business processes.