Platform Events Vs. Push Topic Vs. Change Data Capture

Today the topic under discussion is the difference between “Platform Events”, “PushTopic Events” and “Change Data Capture”, but before we discuss the difference we should first understand that what is a event and what is a event driven software architecture?

Understanding Event-Driven Software Architecture:

Event is basically a thing that happens or takes place, especially one of importance. In Salesforce events are quite useful since they help both the admin and client, e.g. has the assigned task been completed or not? Basically these events notify the admin or the client which helps keep the business running without having them to confirm from someone else(i.e. it saves time).

The paradigm of event-based communication revolves around a publisher-subscriber model—a sender broadcasts a message that one or more receivers capture. It’s like radio transmission—a transmitter tower broadcasts a radio signal, and receivers get the signal if they’re tuned to the right frequency. Much like radio transmission, event-based communication flows from the sender to the receiver. Events get sent whether or not receivers are listening, and receivers don’t acknowledge it when they receive an event. Event-based communication takes place in real-time—or, more accurately, in near-real time.

Before we go any further lets define the components of event-driven architecture:

Event

A change in state that is meaningful in a business process. For example, placement of a purchase order is a meaningful event, because the order fulfillment center expects to receive a notification before processing an order.

Event message

A message that contains data about the event. Also known as an event notification. For example, an event message can be a notification about an order placement containing information about the order.

Event producer

The publisher of an event message over a channel. For example, an order placement app.

Event channel

A stream of events on which an event producer sends event messages and event consumers read those messages. Also called an event bus in Salesforce.

Event consumer

A subscriber to a channel that receives messages from the channel. For example, an order fulfillment app that is notified of new orders.

The following diagram illustrates an event-based software architecture.

Unlike request-response communication models, software architecture built on an event-driven model decouples event producers from event consumers, thereby simplifying the communication model in connected systems. No requests need to be made to a server to obtain information about a certain state. Instead, a system subscribes to an event channel and is notified whenever new states occur. Any number of consumers can receive and react to the same events, which come almost in real-time.

Now that we’re done with the basics of events and event-driven software architecture, we can easily now come to our main topic that is “Platform Events Vs. CDC Vs. PushTopic Events”.

Platform Events:

First of we’ll start with platform events, by defination,

“Platform events enable you to deliver secure, scalable, and customizable event notifications within Salesforce or from external sources via a Message bus”

These Events are based on a publish-subscribe architecture. Platform event fields are already defined in Salesforce and are used to determine the data that you send and receive. They can be published and subscribed to via Apex in addition to the APIs. Platform Events provide the defined notification structure of a PushTopic with a more flexible model than Generic Streaming for raising and subscribing to the events, which means that it’s kind of like the best of both worlds. The events are kept on the bus for a duration of 24 hours so that if the user comes online after sometime he/she can still have access to updates happened during the outage time.

Platform events are a first class object, that means you can setup multiple fields and can have your own structure to publish events. But since they are fired manually so the additional responsibility to manage scenarios for platform events, where SF transaction failed but event has been pushed to Event bus, is added.

Maximum number of platform event definitions that can be created in an org
UE: 100 EE: 50 All other editions: 5

For more information on Platform events checkout: How & What: Salesforce Platform Events (Part 1)

PushTopic Events:

PushTopic Events are basically a part of streaming API events and can be defined as

“PushTopic events track field changes in Salesforce records and are tied to Salesforce records.”

Generally streaming API are used to update UI components. The event notification of a pushtopic event is based on the configured query and event occur they cannot be configured manually. You also have to rely on object fields associated with a query, i.e. multiple fields cannot be used instead only the fields part of a query can be used. In streaming API’s the data was lost when the user got offline but this was changed when Durable PushTopic Events were introduced. The updates are managed by the system.

The generation of PushTopic notifications follows this sequence.

1. Create a PushTopic based on a SOQL query. The PushTopic defines the channel.
2. Clients subscribe to the channel.
3. A record is created, updated, deleted, or undeleted (an event occurs). The changes to that record are evaluated.
4. If the record changes match the criteria of the PushTopic query, a notification is generated by the server and received by the subscribed clients.

Maximum number of topics (PushTopic records) per org
UE: 100 EE: 50 All other editions: 40

Change Data Capture:

Now finally we move onto the CDC or the Change Data Capture events which are the newest edition of the streaming events offered on the Lightning Experience. So basically a Change Data Capture event, or change event, is a notification that Salesforce sends when a change to a Salesforce record occurs as part of a create, update, delete, or undelete operation. The notification includes all new and changed fields, and header fields that contain information about the change.

Use change events to:

• Receive notifications of Salesforce record changes, including create, update, delete, and undelete operations.
• Capture field changes for all records.
• Get broad access to all data regardless of sharing rules.
• Get information about the change in the event header, such as the origin of the change, which allows ignoring changes that your client generates.
• Perform data updates using transaction boundaries.
• Use a versioned event schema.
• Subscribe to mass changes in a scalable way.
• Get access to retained events for up to three days.

The following table compares the features offered by each streaming event