Platform Events Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Platform Events Developer Guide
Delivering Custom Notifications with Platform Events
Defining Your Custom Platform Event
Publishing Platform Events
Subscribing to Platform Events
Set Up Debug Logs
Flows
Processes
Apex Triggers
Platform Event Processing at Scale with Parallel Subscriptions for Apex Triggers
Order of Events in Parallel Subscriptions
Choosing a Partition Key
Parallel Subscription Limits
Parallel Subscription Configuration Examples in Tooling API and Metadata API
Apex Trigger Repartitioning
Configure Parallel Subscriptions for an Apex Trigger
Testing an Apex Trigger Configured with Parallel Subscriptions
Parallel Subscriptions Considerations
Configure the User and Batch Size for Your Platform Event Trigger with PlatformEventSubscriberConfig
Find Uncaught Exceptions in Event Log Files
Resume a Platform Event Trigger After an Uncaught Exception
Retry Event Triggers with EventBus.RetryableException
Email Notifications for Triggers in Error State
Comparing setResumeCheckpoint() and EventBus.RetryableException
Lightning Components
Pub/Sub API
CometD
Group Your Event Streams
Filter Your Event Streams
Obtain a Platform Event’s Subscribers
Identify and Match Event Messages with the EventUuid Field
Testing Your Platform Event in Apex
Encrypting Platform Event Messages at Rest in the Event Bus
Monitor Platform Event Publishing and Delivery Usage
Considerations
Examples
Reference
PDF

Choosing a Partition Key

Which event field you choose for the partition key depends on whether you want to maximize the trigger’s performance or whether the order of event processing is important.

Choosing a Partition Key for Best Performance

For the best performance, and if event ordering isn’t a concern, make sure to select a partition key that contains a wide range of values, such as IDs. That way, the received events are more likely to be evenly distributed across the subscriptions based on the hash value that the system generates for the partition key field. For example, the EventUuid system field or a required custom field containing ID values, such as record IDs, provides a wide range of unique values.

If you choose an event field that doesn’t contain a wide range of values, the processing of partitions can sometimes be less performant. For example, if you choose an event field that contains names of US regions, and if there are more events in the South region, the partition for the South region has more events to process than the partitions for other regions. This processing isn’t efficient.

Avoiding Record Contention and Locking

Depending on your implementation, more than one parallel subscription can attempt to perform a DML operation on the same record, such as a record update. In this situation, a possible result is that the system waits for one partition to finish processing the record before the second partition starts the processing. The record contention can cause latency, delays in event processing, or errors.

To avoid the contention issues, choose a partition key that ensures the placement of events that access the same records in the same partition.

Choosing a Partition Key for In-Order Event Processing

If you want to preserve the order of events for events that have the same partition key, choose a partition key that contains hard-coded values, such as categories or regions. Events with identical partition key values are processed by the same partition in their original received order in the event bus.

For example, if the trigger is configured with two partitions and five events are received, and the first and second event contain a partition key of APAC, they’re processed in order by one partition. The next three events have the partition key of EMEA, and they’re processed in order by another partition.