Salesforce Platform Events vs. Change Data Capture (CDC): The Complete Guide

⚡ Key Points: 1-Minute Summary

• Platform Events: Custom-designed business signals (e.g., OrderShipped__e) that you manually publish to notify decoupled systems.
• Change Data Capture (CDC): Automatic, data-level replication. When a record changes, Salesforce automatically broadcasts the payload for synchronization.
• Durability & Replay: High-volume events are retained on the event bus for 72 hours. Subscribers use a ReplayId to retrieve missed events after a disconnect.
• Modern Consumption: The Pub/Sub API (over gRPC) is the current standard for external consumption, replacing the legacy CometD streaming API.
• Limits: Publishing an event via Apex counts as a standard DML statement. Org-wide hourly publish and delivery limits also apply.

💬 In plain words: Platform Events are custom messages you design and trigger on purpose to announce a business milestone to other systems. Change Data Capture (CDC) is an automatic data stream that says, "Hey, this record just changed," designed specifically for keeping external databases in sync.

📌 Real-Life Example: You create OrderShipped__e with specific tracking and courier fields. This is a business signal published intentionally—a Platform Event. Conversely, if your data lake needs to know every time an Account.Rating changes so it can replicate the update, you don't write custom code. You enable Change Data Capture, and the system automatically broadcasts the raw data change.

🧠 Core Takeaway: Designed vs. Automatic. Platform Events carry YOUR curated message and business intent. Change Data Capture automatically announces record-level state changes for data replication.

🏗️ The Core Concept: Intent vs. Sync

Both Platform Events and CDC ride the Salesforce event bus, but they answer fundamentally different architectural questions:

• Platform Events (__e): These are custom messages you define. You publish them explicitly from Apex using EventBus.publish(), from Salesforce Flow, or via the API. They carry business intent with a highly curated payload that you design.
• Change Data Capture (CDC): This is automatic. Once enabled for an object, the platform publishes a change event for every create, update, delete, and undelete. It broadcasts exactly what happened to the data, making it the perfect tool for state replication.
• The Subscribers: Both event types share the same listening mechanisms. Inside Salesforce, they are consumed by Apex triggers, Flows, or LWC (via empApi). Outside Salesforce, they are consumed via the modern Pub/Sub API (gRPC) or the older CometD layer.

🧭 360 Card — Platform Events & CDC

Rule: Platform Events carry a business signal you designed. Change Data Capture broadcasts raw record changes automatically.
Gain: Extreme decoupling. Publishers don't need to know who is listening. A single event can trigger five different downstream systems without modifying the publisher code.
Reach for: Use CDC when you simply want to mirror data changes elsewhere. Use Platform Events when you are choreographing a business process (like approving an order). Reach for Event Relay when your consumer is in AWS to skip building custom middleware.
Price: Delivery is not infinite. If a downstream subscriber goes offline and misses the 72-hour retention window, those events are gone forever.
Limits: High-volume events are retained for 72 hours. (Legacy standard-volume events are slated for retirement in June 2027). Calling EventBus.publish() consumes a DML statement limit.
Mirror: A nightly batch reconciliation job. While slower, it guarantees no missed records. Robust enterprise designs often use both: events for speed, batches for safety.

⚠ INTERVIEW TRAP: If an architect asks what happens if a subscriber is offline for a week, never say, "Events are fire-and-forget, so we just lose them." The correct answer is that the architecture must include a periodic reconciliation batch (a delta query on SystemModstamp) as a safety net for outages that exceed the 72-hour retention window.

💬 Core Q&A

Q: Why would one integration use BOTH CDC and Platform Events rather than just one?

🎯 Say this first: "CDC streams raw data changes for synchronization. Platform Events broadcast curated business intent. Most enterprise integrations require both contexts, and their platform limits count separately."

A: Because "data changed" and "a specific business milestone occurred" are completely different contracts.

• You use CDC to seamlessly replicate Account and Contact edits into your Snowflake data warehouse. You get automatic field-level tracking without writing a single line of publish code. However, CDC is "chatty"—it fires on every minor edit, and consumers have to reverse-engineer business intent from raw field diffs.
• You use Platform Events for a signal like CreditCheckRequested__e. You publish it deliberately, exactly when needed, with a clean payload acting as an API contract.
• If you only use CDC, external systems break when your internal Salesforce data model shifts. If you only use Platform Events, you end up manually coding publish triggers for basic data replication (which is a massive waste of time). A mature architecture pairs CDC for state replication and Platform Events for process choreography.

Q: How do platform event limits actually count? Is publishing considered DML?

A: Yes. Publishing an event from Apex using EventBus.publish() counts exactly as a standard DML statement against your transaction's governor limits. It also counts toward your total DML rows.

• Transaction Limits: It consumes limits whether called in synchronous or asynchronous Apex.
• Hourly Allocations: The org has a strict limit on events published per hour.
• Delivery Limits: There is a separate 24-hour limit for events delivered to external CometD/Pub-Sub clients. (Internal Apex trigger subscribers do NOT consume this external delivery allocation).
• Publish Behavior: Always choose your publish behavior wisely. Publish After Commit (the default) ensures the event only fires if the database transaction succeeds. Publish Immediately fires the event instantly, even if the surrounding transaction ultimately rolls back.

Q: A CDC-based sync intermittently misses changes during deploy windows and subscriber restarts. What's the durability story and fix?

A: The Salesforce event bus retains high-volume events for 72 hours. Every event carries a unique ReplayId.

• A well-architected external subscriber must durably store the last processed ReplayId in its own database (not just in memory).
• When the subscriber restarts, it resubscribes using that specific ReplayId. Salesforce will instantly deliver any events that occurred during the downtime.
• You can also pass special values: -1 subscribes only to new events arriving from this moment forward, while -2 retrieves everything still retained in the 72-hour window.
• To completely bulletproof the integration, build a reconciliation sweep (a scheduled query checking SystemModstamp) to catch any discrepancies that exceed the 72-hour retention limit.

Q: Are PushTopics and generic streaming events still relevant? What is Event Relay?

A: PushTopics and generic events belong to the legacy streaming layer. While they still run in older orgs, absolutely nothing new should be built on them today. The modern Pub/Sub API over gRPC, combined with Platform Events and CDC, is the definitive replacement.

Event Relay is a game-changing native feature that pipes Platform Events and CDC directly into Amazon EventBridge. If your downstream consumer lives in AWS, Event Relay completely eliminates the need to build, host, and maintain custom middleware just to listen to the Salesforce event bus.