Reliability guide · Salesforce CDC
A CDC subscription is a stream, not a guarantee. Make the local rows trustworthy anyway.
Event-driven updates are the right low-latency path for a Salesforce mirror. But they need a companion design for retries, outages, event ordering, source changes, and the period after an event can no longer be replayed.
Define the change contract before subscribing.
Change Data Capture is most useful when it follows an explicit mapping. Decide which objects emit changes, which fields are represented locally, how parent/child dependencies behave, and whether the consumer fetches the current source record or applies the event payload directly.
Do not assume global ordering across all related records. A child change can arrive when a parent row is missing locally, a retry can arrive twice, and a deletion needs deliberate semantics. Those are normal conditions that the write model should tolerate.
The event stream and any enrichment reads are only as complete as the integration user’s object and field permissions. Validate the mapping under the same user you will run in production.
Make the write and the checkpoint one unit of progress.
For each event, write the corresponding destination row idempotently. Then persist the replay position after the write is committed. If the worker restarts between those two moments, replaying the same event should be safe; if it restarts before the write succeeds, it should not skip ahead.
In practice, idempotency means the destination has a stable source identity, updates can be repeated without changing the end state incorrectly, and deletes are either represented as a durable deletion state or removed with a reconciliation process that can detect their absence.
Recover from short outages, then prove completeness.
When a worker loses connectivity or restarts, resume from the last durable replay position. Monitor the backlog and report when the stream is catching up. That handles ordinary restarts and temporary service disruptions.
However, replay has a finite retention window. A longer interruption, a changed mapping, or a permissions issue cannot be solved by replay alone. That is why an application mirror needs a reconciliation job even if normal CDC lag is only seconds.
Replay: resume from the last successful checkpoint after a short interruption.
Retry: make retries visible and bounded; retain a failed-record queue for inspection.
Backfill repair: re-read a scoped set of source records when recovery cannot rely on replay.
Operator signal: surface lag, stale checkpoint age, and unresolved failures in one place.
Reconcile the data that matters, on purpose.
Reconciliation is not necessarily a full-org reload. Start with the selected objects and the fields tied to the application workflow. Compare counts, source IDs, deletion states, and a small set of important values. When the difference is acceptable, record it; when it is not, repair the affected slice and leave an audit trail.
The schedule should match business risk. A support portal may accept a daily integrity check. Entitlement, revenue, or provisioning workflows may need tighter checks and specific alerts. The goal is a clear, explainable data contract—not a vague promise of real time.
Production checklist
Confirm CDC access: selected objects, event allocation, and integration-user permissions.
Backfill before live cutover: establish complete local rows before relying on incremental events.
Use idempotent writes: retries and replays cannot produce duplicate application data.
Checkpoint after commit: the stream position never gets ahead of the database state.
Run reconciliation: practice recovery and document who owns a detected mismatch.
Need a reliable CDC path?
CRM Sync pairs change capture with backfills and reconciliation so the local rows stay useful when the stream is not perfect.