How to Stay Within Salesforce Platform Event Limits Using CDC Filtering

TL;DR

• CDC emits all changes, not all are useful
• Filter events before publishing to reduce PE usage
• Use custom PE layer for deduplication
• Avoid pushing filtering to consumers or middleware

Stop Paying for Noise: Rethinking CDC and Platform Event Usage

Most Salesforce implementations don’t overthink event architecture at the start. You enable Change Data Capture, wire it to an external system, and move on. It works. Data flows. Nobody complains.

Then one not so fine day, limits show up. Not as a theoretical constraint, but as a bill or a failed integration. Platform Event allocations, which looked generous at first, suddenly feel very finite. And now every event you publish is no longer just data. It’s cost.

That’s when an uncomfortable realization hits: you’re not just sending important changes. You’re sending everything.

The Problem Nobody Notices Early

CDC is indiscriminate by design. When a record changes, an event fires. It doesn’t care whether that change is meaningful to your downstream systems.

A minor field update, a system-triggered change, a sequence of rapid updates on the same record, all of it gets emitted. And if your architecture is set up to forward those events externally, all of it gets delivered too.

Which means you’re effectively paying to transmit noise. The problem isn’t CDC. The problem is what you choose to do with it.

A Small Shift in Thinking

Salesforce limits the events that are subscribed by external systems, but internal events are not limited by quote. So, start with this question "Do we really need to send all events to external systems?". When you answer that question, you realise that "Not every event deserves to leave your org". That one decision changes the architecture from the full-flowing pipe into something that is controlled.

This is how it looks like in practice:

Simple, clean, and expensive at scale.

A more deliberate approach introduces a control layer:

At first glance, this looks like unnecessary indirection. Another hop, another component, more logic. But the behavior changes completely. Now, before anything is published externally, it passes through a decision point.

Filtering Is Only Half the Story

The CDC triggers provide you the full context of what changed. You can apply filters based on which fields changed. If a change doesn’t matter, you drop it. That alone reduces volume significantly.

But filtering isn’t enough.

In real systems, the same record can generate multiple CDC events in a short span. Updates cascade, automations fire, and suddenly you have a burst of events that all describe intermediate states. Forwarding all of them is technically correct and practically useless.

This is where you need the second layer: A custom platform event.

You get a place to stabilize the stream by routing through a custom Platform Event. You can dedupe events, collapse multiple updates into one meaningful signal, and ensure that what leaves your system represents intent, not noise.

For example: you can collect events for a identical records, and send one, up-to-date message, instead of sending a bunch.

Why to solve this at Platform itself?

You could push this responsibility downstream. Let the consumer filter. Let middleware handle it. Let someone else deal with the mess.

But by the time an event reaches those layers, it has already been published, counted against the quota limits, and transmitted. The cost is already incurred. The complexity has already spread.

That's why handling it at the source is less convenient, but far more effective.

The Cost Savings

Without this control, event volume grows with system activity. Not with business significance, but with raw change frequency.

That’s how you end up scaling limits for the sake of redundant updates.

Once you introduce filtering and deduplication, the volume starts to reflect actual business signals. Fewer events, clearer intent, and a system that behaves more predictably.

• For consultants, this becomes a straightforward cost optimization lever.
• For ISVs, it prevents quietly exhausting subscriber limits.
• For enterprises, it reduces unnecessary load across the entire integration layer.

The Tradeoffs You Shouldn't Ignore

This approach isn’t free.

You’re adding a layer, which means more logic to maintain and more places where things can go wrong. There’s additional latency, even if small. Deduplication introduces ordering concerns. Debugging becomes less linear because events don’t flow directly anymore.

None of these are dealbreakers, but pretending they don’t exist is how systems become fragile.

Conclusion

This isn’t a complex pattern. It’s a control mechanism that most teams skip because the naive version works well enough in the beginning. By the time limits force the conversation, the architecture is usually too entangled to fix cleanly.

Adding a simple evaluation layer early keeps the system honest. It ensures that what you send out actually matters.

And in a system where every event has a cost, that’s not an optimization. That’s basic discipline.

Frequently Asked Questions

Q1. What are Salesforce Platform Event limits?
A: Daily allocation (~50K base) limits how many events you can publish externally. Additional capacity costs extra.

Q2. Why does CDC increase Platform Event usage?
A: CDC emits events for every change, including low-value updates, which increases event volume quickly.

Q3. How can I reduce Platform Event usage in Salesforce?
A: Filter CDC events before publishing and deduplicate events using a custom Platform Event layer.

Q4. Should I filter events at the consumer or producer level?
A: Producer level. Filtering at the consumer wastes event quota and increases system load.

Q5. Can middleware like MuleSoft or Kafka solve this problem?
A: Partially. But events are already published and counted before reaching middleware, so cost savings are limited.

Q6. Why use a custom Platform Event for deduplication?
A: It allows consolidation of multiple CDC events for the same record into a single meaningful event.