Using Salesforce Platform Events for Decoupled, Asynchronous Integration

Problem: Need Decoupled Asynchronous Integration

When external services must react to Salesforce data changes without waiting for a synchronous API call, a publish‑subscribe pattern is preferred. Platform Events provide a built‑in, managed event bus that eliminates tight coupling, reduces timeout risk, and scales with high‑volume data ingestion.

Requirements

• Salesforce org with API access (Enterprise or Unlimited edition).
• At least one custom Platform Event object defined (e.g., Order_Updated__e).
• Publishers: Apex triggers, batch jobs, or external apps using REST or SOAP.
• Subscribers: CometD clients, Platform Event triggers, or external services via Streaming API.
• Idempotent consumer logic if events are delivered at least once.
• Monitoring: Event usage reports, debug logs, and optional external metrics.

Smallest Suitable Design

The minimal architecture consists of a single Platform Event object, an Apex trigger that publishes the event, and an external system that subscribes to the event channel via the Streaming API. No additional middleware is required.

// Apex Trigger (run after update of Order object)
trigger OrderTrigger on Order (after update) {
    List events = new List<Order_Updated__e>();
    for (Order o : Trigger.new) {
        Order_Updated__e ev = new Order_Updated__e(
            OrderId__c = o.Id,
            Status__c = o.Status,
            UpdatedAt__c = System.now()
        );
        events.add(ev);
    }
    // Publish after commit to avoid sending on rollback
    Database.SaveResult sr = EventBus.publish(events, true);
}

On the external side, a CometD client subscribes to /event/Order_Updated__e. The client must maintain a replayId to recover missed events.

Trust and Data Boundaries

• Platform Events are tenant‑isolated; only users with the Read Platform Events permission can subscribe.
• Event payloads are limited to 1 MB; large data sets should be stored in a separate object and referenced by ID.
• Data privacy: Do not include PII in the event unless the external system is fully trusted and compliant.
• Governors: 10,000 events per hour per org; 1,000,000 events per day per org (limits vary by edition).

Operational Checks

1. Publish After Commit: Verify that events are only emitted when the transaction succeeds. Trigger a rollback in a test and ensure the event does not appear in the event stream.
2. Replay Verification: Use Workbench or a CometD client to request events from a known replayId and confirm that missed events are retrieved.
3. Rate Limits: Monitor the Event Usage report and EventBus debug logs to stay below governor limits.
4. Idempotency: Log Event Id in the consumer and reject duplicates to avoid duplicate processing.

Failure Modes and Mitigation

Failure	Impact	Mitigation
Event not delivered (network outage)	Consumer misses data	Replay from known ID; store last processed ID in durable storage.
Duplicate event delivery	Idempotent processing required	Track event IDs; ignore repeats.
Payload exceeds 1 MB	Publish fails	Chunk data or reference via ID.
Governor limit exceeded	Publish throttled or blocked	Batch events; back‑off strategy.

When to Change the Design

• High‑throughput, low‑latency requirement: If the consumer needs real‑time processing with sub‑second latency, consider integrating with a dedicated message broker (e.g., RabbitMQ) and use Platform Events only for backup or non‑critical flows.
• Critical synchronous workflows: If the external system must complete a transaction before the Salesforce record commits, use synchronous REST calls or the External Services feature instead of events.
• Complex routing or transformation: If events need to be enriched, filtered, or routed to multiple systems, introduce an integration platform (MuleSoft, Informatica) that consumes Platform Events and orchestrates downstream services.
• Compliance or audit requirements: If every event must be logged with cryptographic assurance, extend the event payload with a signed hash and store the signature in Salesforce.

Practical Verification Steps

1. Create the Platform Event object via Setup → Custom Objects → New Custom Object, name it Order_Updated__e, and add fields OrderId__c (Text), Status__c (Picklist), UpdatedAt__c (Date/Time).
2. Publish a test event using the Developer Console: EventBus.publish(new Order_Updated__e(OrderId__c='001xx000003NG', Status__c='Closed', UpdatedAt__c=System.now()));
3. Subscribe via Workbench: Navigate to Streaming API, create a new subscription to /event/Order_Updated__e, and observe the event payload.
4. Trigger a rollback: In a test trigger, throw an exception after publishing; verify that the event is not delivered.
5. Check the Event Usage report to confirm that the published event counts against the org’s limits.

Takeaway

Platform Events are a lightweight, managed solution for decoupled, asynchronous integration. By publishing only after a successful transaction, respecting governor limits, and implementing idempotent consumers, you can build resilient integrations that scale with your data volume. If your use case demands stricter guarantees or lower latency, augment or replace the event bus with a dedicated middleware layer.