In the world of Salesforce development, Platform Events are often hailed as the “magic wand” of integration. They are secure, scalable messages that follow a publish/subscribe (pub/sub) model, allowing different parts of your system—or even external systems—to communicate without being tightly coupled.
However, there is a fine line between an elegant event-driven architecture and a “trap” that can bring your org to its knees. Understanding how to leverage the asynchronous nature of these events is the key to mastering the platform.
The Anatomy of a Platform Event
Unlike standard custom objects, Platform Events are transient. You cannot update or delete event records; they are immutable streams of data.
- Publishers: Apex, Flows, or APIs send the event.
- Subscribers: Triggers, Flows, or External Systems listen and act.
The defining characteristic of these events is that they are asynchronous. They run in a separate transaction from the one that triggered them, which leads us to one of the most powerful patterns in Salesforce architecture.
The “Good” Trap: The Asynchronous Logging Pattern
The most common intentional “trap” is an architectural pattern used to catch and store errors that would otherwise be lost during a database rollback.
The Problem: Transactional Rollback
In standard Apex, if a transaction hits a validation rule or a limit, the entire process rolls back. If you wrote code to log that error into a custom Error_Log__c object, that log record vanishes along with the failed transaction. You’re left with a broken process and no footprints to follow.
The Solution: The Platform Event Trap
By using a Platform Event with the “Publish Immediately” behavior, you can “trap” the error details before they disappear.
- Catch the Exception: Wrap your logic in a try-catch block.
- Publish the Event: In the catch block, publish an Error_Event__e.
- Immediate Persistence: Because it is set to “Publish Immediately,” the event exits the transaction the moment it is called. It doesn’t care if the main transaction fails or rolls back later.
- Subscriber Action: An Apex trigger on the event picks up the message and inserts an Error_Log__c record in a brand-new transaction.
The “Bad” Trap: Common Pitfalls to Avoid
While the logging pattern is powerful, several traps can lead to performance degradation or “infinite loops.”
1. The Recursion Trap
This is the most dangerous scenario. If a Platform Event trigger performs an update on a record that, in turn, publishes the same Platform Event, you create an infinite loop. This will rapidly consume your hourly event limits and can lock up your org’s processing resources.
2. The Governor Limit Trap
Platform Event triggers run under the Automated Process user. While they have their own governor limits, they are not infinite. If you publish thousands of events and your subscriber trigger is not “bulkified,” you will hit CPU timeouts or DML limits, causing the events to fail silently.
3. The “Publish After Commit” Confusion
If you set your event to “Publish After Commit,” the event only sends if the main transaction succeeds. If you are trying to use this for error logging, it will fail. The event will be rolled back along with the error, defeating the purpose of the trap.
Best Practices for Platform Event Design
To ensure your architecture remains a tool rather than a debt, follow these industry standards:
| Feature | Best Practice |
| Volume | Use High-Volume Platform Events for better scalability. |
| Error Handling | Always use EventBus.RetryableException to handle transient failures. |
| Security | Remember triggers run as “Automated Process.” Ensure this user has the necessary permissions. |
| Testing | Use Test.getEventBus().deliver(); in Apex tests to simulate async delivery. |
Real-World Case: The Order Integration
Imagine an e-commerce integration where an “Order Placed” event is published.
- The Intent: A subscriber trigger sends data to an external ERP.
- The Trap: If the ERP is down, the trigger fails.
- The Fix: Implement a “Retry Trap.” The failure is caught, a “Retry” event is published with a timestamp, and a secondary subscriber attempts the integration again after a delay, ensuring no order is lost.
Conclusion
A Platform Event Trap is a double-edged sword. When used as a design pattern for asynchronous logging, it provides unparalleled visibility into system failures. However, without careful management of recursion and governor limits, it can become a technical debt trap. By prioritizing quality over quantity and ensuring every event has a clear, non-recursive path, you can build a robust, event-driven ecosystem.
Leave a Reply