How to improve your events Architecture

Introduction

This article assumes you are familiar with Platform Events, what is a Producer, a Consumer, the Salesforce Event Bus and a Custom Channel.

The Event Lifecycle in Salesforce involves several technical steps that are important to comprehend, that I split in 5.

Let’s review them down and explore each stage in detail:

1. Event Publishing Request:
   • The Producer initiates a request to publish an event through the Event Bus .
   • This request is processed synchronously but does not guarantee success.
   • The event is initially stored in a shared resource pool, separated from the Event Bus.
   • We can track the outcome of this operation, including any failures.
2. Moving Events to the Event Bus:
   • In an asynchronous transaction, events are moved from the shared resource pool to the Event Bus.
   • This process operates behind the scenes.
   • Events are inserted into the Event Bus asynchronously, which may introduce delays. This operation can fail, although before Spring ’23, such failures could not be traced.
   • However, in GA Summer ’23, an Apex Callback is introduced to obtain success/failure information upon sending messages to the Bus.
3. Salesforce’s Responsibility and Blind Spot:
   • The first two steps represent Salesforce’s responsibility and design choices.
   • Salesforce assumes that consumers will receive the events but lacks mechanisms to prove it.
   • Unfortunately, there is no logging or evidence to verify if a consumer received, discarded, or deleted an event.

Mitigations for this issue are discussed in this article to address potential challenges and frustrations when dealing with consumers’ complaints about missed events.

Once an event reaches the Event Bus, the following steps occur:

4. Consumer Subscription:
   • Consumers can subscribe to events or custom channels using different methods:
     • Triggers can declare an after-insert operation on an event.
     • CometD or Pub/Sub clients implement a subscription process using provided credentials for authentication and authorization via API calls.
   • While trigger-based subscriptions can be managed in the Salesforce UI Setup, subscriptions for CometD and Pub/Sub consumers cannot be traced currently.
   • Salesforce does not have immediate plans to provide a list of external consumer subscriptions.
   • It’s important to note that having a subscription does not guarantee an active and listening subscription. Changes in credentials can lead to unintended unsubscription, which cannot be traced.
5. Event Reception by Consumers:
   • Consumers subscribed to events or channels receive the corresponding events from the Event Bus.
   • However, it is crucial to understand that consumers might have bugs or issues that cause them to discard received events.
   • Salesforce does not log the sending of events to consumers or provide acknowledgement of event reception.
   • As a TDE/SDE, it’s essential to acknowledge the absence of logs or evidence to prove event sending and reception by consumers.

Expiration and Deletion policy:

• After 72 hours, events are automatically deleted from the Event Bus and are irretrievably lost.

Once the process is cleared and the challenges and the intricacies of the Event Lifecycle surfaced let’s review the new remediation provided in the last Salesforce release.

How to improve your architecture

For Step 1

1. When you create and publish an event message using Eventbus.publish method, you get back a Database.SaveResult object that contains the synchronous result, check for errors.
2. If there are no errors, this only means that the publish operation was queued in Salesforce, no guarantee of publication.

For Step 2

1. With the new Publish callback, you can get the final result through an Apex callback that you implement.
2. Event publishing is asynchronous, and the immediate result returned in SaveResult is the result of queuing the publish operation in Salesforce.

For Step 3 and 4

1. No available capability on the Salesforce platform provides the information that a subscriber received an event. This leaves you without any confirmation about which subscribers received which messages.
2. So, a simple solution is using a trigger to receive the event, let’s call it the Policeman Trigger.
3. Ideally, this Trigger will subscribe to a custom channel, having all platform events as channel members included, but unfortunately, the Salesforce Architecture does not provide this capability for triggers, So you need to create a Guardian AfterInsert Trigger per every Event we want to monitor is published
4. Cometd consumers are able to subscribe not only to events but also to Custom Channels. This capability allows to provide a similar scenario to the trigger but using a unique CometD subscriber:

So with the recent release of the publish callback one blind spot has been mitigated, what is good news if you are using this architecture pattern.

I personally tested this new callback on the pilot phase and worked like a charm so kudos to the Salesforce internal team that made it possible and encourage them to apply some more improvements like correlative IDs, etc.

Links

• https://help.salesforce.com/s/articleView?id=release-notes.rn_platform_events_publish_callbacks.htm&release=244&type=5
• Get the Result of Asynchronous Platform Event Publishing in Apex (Pilot) (salesforce.com)