Durable Salesforce Event Replay in MuleSoft: Object Store, Checkpoints, and Idempotency
Replay is a recovery mechanism, not a substitute for reliable processing. A production Salesforce event consumer needs both a durable position and idempotent business handling.
The checkpoint problem
Suppose Mule receives event R105.
If it stores R105 as the checkpoint before downstream processing and then crashes, the application may restart after an event it never completed.
If it processes downstream first and crashes before storing R105, the event can be delivered again. That is usually safer - but requires idempotency.
receive R105
→ process downstream durably
→ persist R105
This is an at-least-once style recovery posture: duplicates are possible; silent gaps are minimized.
MuleSoft Object Store replay option
Salesforce Pub/Sub Connector supports Replay id from object store. The source reads a replay ID from the configured Object Store name/key. MuleSoft's documentation states that if the value isn't found, the option defaults to Earliest.
That default is important. Test first-start behavior intentionally so a deployment does not unexpectedly consume the full retained window.
Idempotency key
A replay ID is useful for positioning, but business deduplication may need a domain key or event identity. Choose a key that represents the side effect you must not repeat.
For example:
consumer = inventory-sync
business record = Order 80122
change/event identity = durable event identifier
Persist processed identity only at the point where the associated side effect is durable.
Multiple consumers
Do not casually share one checkpoint across independent consumers. Each consumer may have a different processing position and recovery requirement.
Retention is finite
Replay only works while the required event is still available from Salesforce. If an outage exceeds the retention window, you need a reconciliation path - often a SOQL/Bulk API comparison or another authoritative source - not wishful replay.