We have integration use cases to external partners(5 to 6 of them) which we will integrate using mulesoft.

When data gets updated in case object we will do a callout to mulesoft and based on certain criteria mule will send it out to different partners.

We were evaluating between apex callout and platform event for meeting this requirement.

Once the request goes to mulesoft its asynchronous, mule will come back and update salesforce at a later point of time.

Is this a good use case for platform events.


  1. we will have millions of requests so we will need to use high volume platform events which will come with cost
  2. we are not going to integrate with multiple partners straight as we will go through mulesoft for all callouts
  3. What benefits do we get by using platform events over callouts since PE comes with cost factor.
  • 1
    I see this as a use case for CDC instead, have you reviewed that? I personally won't recommend a callout here.
    – Jayant Das
    Mar 9, 2020 at 13:01
  • @JayantDas - any reasons why you would prefer CDC/Platform events over callouts?
    – RedDevil
    Mar 9, 2020 at 13:35
  • 1
    Consider this from an architecture point of view. You have a middleware already in place, you'll want to utilize the capabilities of the m/w instead of having your developers write an apex callout. Then also factor in why you are building this - data vs. service. If you are making an apex callout, then I would assume you will also need to build a service at mulesoft to accept the request from salesforce. With the infrastructure already available where you can always subscribe to the data changes, utilize those instead of any customization.
    – Jayant Das
    Mar 9, 2020 at 13:51
  • @JayantDas , makes lot of sense around re-using whats there existing
    – RedDevil
    Mar 9, 2020 at 13:58

2 Answers 2


I have faced similar dilemma a few months back, here are the points that made me consider the architecture.

1) Callouts from Trigger: You would basically do it in Future, Queueabale or if you run periodically in batch/scheduler. You will consume AsyncApexLimits then. Am not sure how many do you have in your org, you can't buy them directly, you have to buy licenses to increase it.

2) NO SLA in Async Apex : There is no SLA when async apex will execute, I have seen future queuable run after 10, 20 minutes.

3) Build Retry mechanism: Yes, it will fail sometimes. Now if you go with callout you have the responsibility of retrying. Again that would be limits consumption

If cost is your main concern, I have a workaround.

The limit of platform events allocation is only when you consume those events using API, emp-connector or mulesoft. (https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

I generally go with the two options:

1) Create a platform event with long text area(max size), and in after update trigger, create a JSON of changed fields and dump it in the platform event. Thus in a single event, you can send data for multiple records

2) Subscribe to CDC event in SF via apex trigger(No Limits), CDC trigger can run in chunk of upto 2000 records at a time, serialize them in JSON and publish a single platform event with these.

  • +1 @pranay great points. for 2, the maximum event size is 1 mb, will combining 2000 records cause size to be exceeded? and also if CDC publishes 2000 records is each record counted as one event or all 2000 together is counted as one when you pubish it to subscriber like mulesoft.
    – RedDevil
    Mar 13, 2020 at 9:11
  • The maximum batch size for Platform Event Trigger , CDC Trigger in APEX is 2000 records. This is not the case when you subscribe CDC event via comet D. Each changed record has replayId, and as they are individual entity they consume 2000 CDC deliverability limits. Mar 13, 2020 at 11:02
  • @david-reed - i would like to award bounty to pranay as well, is that possible?
    – RedDevil
    Mar 16, 2020 at 17:30

Disclaimer: I work for Salesforce. I'll talk about architecture only. I won't discuss costs.

I'll start by putting Platform Events (PE) and Change Data Capture (CDC) in the same Streaming APIs basket as they both rely on the same underlying technology (CometD).

Here are two main things to take into consideration when comparing Callouts with the Streaming APIs in the context of Salesforce Org to MulesSoft communication:

1. Transport and Architecture

Callouts are point to point only whereas Streaming APIs are broadcast. Streaming APIs allows for event-driven architectures and decoupling. With that, you can easily expand your architecture in the future and limit refactoring. For example, if you need to log things or extract data for reporting, you just need to add a new event subscriber.

2. Durability

Streaming APIs events can be replayed for up to 72 hours whereas callouts can't. That's interesting in case you have a planned or unplanned service downtime. All you'll have to do to recover is to replay the calls you missed.

Choosing between PE or CDC

If you go for the Streaming APIs, here's a piece of advice on how to choose between PE and CDC:

  • if you only pass case data then go for CDC. Consider the CDC Enrichment pilot to add extra case fields to your CDC events if needed.
  • if you need to aggregate data from multiple objects/records, go for PE.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .