Event Message Durability
Salesforce stores platform events and change data capture events for 72 hours. Using Pub/Sub API, you can retrieve events that are within the retention window. Retrieving stored events is helpful after the client disconnects and wants to catch up on missed events.
After the retention period, events are purged from the event bus. The purging process sometimes starts later, and as a result, platform events and change data capture events that are older than 72 hours can still be available. Salesforce doesn’t guarantee the storage of events beyond the retention period of 72 hours.
Each received event message is assigned an opaque ID contained in the Replay ID field, represented as ConsumerEvent.replay_id in the protocol specification. The Replay ID field value, which is populated by the system when the event is delivered to subscribers, refers to the position of the event in the event stream. Replay ID values aren’t guaranteed to be contiguous for consecutive events. A subscriber can store a replay ID value and use it on resubscription to retrieve events that are within the retention window. For example, a subscriber can retrieve missed events after a connection failure. Subscribers must not compute new Replay IDs based on a stored Replay ID to refer to other events in the stream.
The replay_id field value isn’t guaranteed to be unique when Salesforce maintenance activities occur, such as an org migration. To uniquely identify a platform event message, use the event id field. When publishing an event, the field is ProducerEvent.id. For more information, see Identify an Event with ProducerEvent.id and PublishResponse.correlationKey. For a received platform event message, use the ConsumerEvent.event.id field. The id field is present on platform events and not on change events.
To catch up on missed events during client shutdown, you can retrieve events that are temporarily stored in the event bus. By using the Subscribe RPC Method with a replay_preset option, a subscriber can choose which events to receive, such as all events starting after a particular Replay ID. To do so, the client stores the Replay ID of the last processed event.
This high-level diagram shows how event consumers can read a stream of events by using various replay options.
Instead of managing the Replay ID on the client with the Subscribe RPC method, you can use the ManagedSubscribe RPC Method (Beta) to more easily track the events received. With ManagedSubscribe, you commit the Replay ID of the last processed event on the server. You don’t worry about managing a replay ID store on the client. Then when resubscribing, the subscription resumes after the stored Replay ID.
See Also