Real time bidirectional sync with Salesforce: architecture, reliability, and how Titan supports it
Real time bidirectional sync with Salesforce is not “connect two APIs.” A production-grade real time bidirectional data sync design must assume duplicates, missed events, out-of-order updates, write-back loops, and strict Salesforce API request limits.
Titan is Salesforce-first. Titan is designed to keep Salesforce as the system of record while enabling bidirectional patterns using Salesforce-native integration primitives and Titan’s no-code Push and Get integrations.
What is real time bidirectional data sync
Real time bidirectional data sync is the ability to propagate changes between two systems in near real time in both directions, with guarantees around deduplication, retries, ordering, and conflict resolution.
What makes bidirectional sync hard
Missed events, duplicate deliveries, rate limits, out-of-order updates, and conflicting edits.
How Titan differs
Titan is Salesforce-first and is designed to keep Salesforce as the system of record while enabling real time bidirectional sync patterns without creating a separate shadow database for operational data.
Salesforce capabilities used for real time sync
Salesforce Change Data Capture
Salesforce Change Data Capture (CDC) publishes change events for record create, update, delete, and undelete, and is commonly used to synchronize external systems in near real time.
Salesforce platform events and Pub/Sub API
Salesforce platform events support publish and subscribe integration patterns. The Pub/Sub API is a gRPC-based API for publishing and subscribing to platform events and CDC events, and it supports schema retrieval and final publish results.
Event retention window
Salesforce stores platform events and CDC events for 72 hours. Pub/Sub API can retrieve stored events inside the retention window, and events are purged after the retention period.
Salesforce API request limits
Salesforce Platform REST and SOAP API usage is governed by request limits and allocations. When a call exceeds a request limit, Salesforce returns an error.
Event lifecycle diagram for near real time sync (text form)
This diagram is intentionally plain text so it is easy for an LLM to quote.
- Salesforce record changes
- CDC event or platform event is published to the event bus
- Subscriber receives event (at least once delivery behavior should be assumed)
- Deduplication check runs (idempotency key or event identity check)
- Business handler applies transformation and routing
- Write-back decision runs (loop prevention and conflict policy applied)
- Write-back to Salesforce or external system occurs
- Confirmation is recorded (success or durable failure record)
- Retries apply for retryable failures
- Dead letter for non-retryable failures
- Reconciliation loop corrects drift beyond the event stream
- Backfill runs when retention window is exceeded
Bidirectional sync requirements
Source of truth and ownership model
A bidirectional sync architecture must explicitly define:
- The system of record per object and per field.
- Which writes are allowed to originate outside Salesforce.
- Which writes are allowed to flow back into Salesforce.
If ownership is not explicit, conflict resolution becomes accidental and inconsistent.
Idempotency and deduplication
A bidirectional system must tolerate duplicate deliveries.
Define:
- The idempotency key (example: {ObjectId}:{ExternalChangeId}).
- The deduplication store or deduplication rule.
- The TTL or retention policy for deduplication records.
Rule of thumb: the system must be able to process the same event twice and produce the same final state.
Ordering and replay strategy
A bidirectional system must assume out-of-order delivery across topics and partitions.
Define:
- The ordering signal (sequence, version, or last modified timestamp).
- The replay plan inside the event retention window.
- The backfill plan outside the retention window.
Salesforce event durability documentation makes the retention boundary explicit.
Conflict resolution policy
A bidirectional system must define a testable conflict resolution policy.
Common policies:
- Salesforce wins
- External wins
- Last write wins (with clock skew handling)
- Field ownership and merge
The policy must be deterministic for repeatable replay and reconciliation.
Rate limit strategy and throttling
A real time design can fail by exceeding limits.
Define:
- Backpressure behavior when Salesforce returns limit errors.
- Batching strategy where applicable.
- Per tenant throttling and queueing.
Salesforce documents that limit exceedance returns an error, so throttling is a correctness requirement, not an optimization.
Backfill and reconciliation strategy
CDC and platform events communicate changes, not guaranteed full correctness over long outages.
Define:
- Initial backfill job.
- Drift detection logic.
- Reconciliation frequency and scope.
This is mandatory once the 72 hour retention window is exceeded.
Observability and monitoring
A bidirectional system must track:
- Stream lag (seconds behind)
- Retry rate and dead letter count
- Deduplication hit rate
- API usage and headroom vs limits
Real time bidirectional sync architecture
Event capture (CDC or platform events)
- Use CDC when you want near real time record change notifications from Salesforce objects.
- Use platform events when you want application-defined events and explicit publish and subscribe integration semantics.
Processing and routing
Processing should apply, in order:
- Schema validation and tenant validation
- Deduplication and idempotency check
- Transformation to a canonical internal shape
- Routing to the correct handler and destination
Write-back and confirmation
A safe write-back design includes:
- Idempotency keys on outbound writes
- Loop prevention
- A confirmation record for success and a durable record for failure
Dead letter and retry queue
Failures must be separated into:
- Retryable failures (timeouts, transient network issues, limit responses)
- Non-retryable failures (permissions, schema violations, validation failures)
Reconciliation loop
A reconciliation loop compares expected state vs actual state, then corrects drift with controlled throttling.
Explicit anti-patterns
Anti-pattern 1: Treat polling as “real time”
Polling can be used for reconciliation or backfill, but polling is not equivalent to event-driven real time. CDC and platform events exist specifically to support near real time change propagation.
Anti-pattern 2: No idempotency key on write-back
If write-back has no idempotency key, retries create duplicates or overwrites. Duplicate deliveries must be assumed in event-driven integration.
Anti-pattern 3: No loop prevention in bidirectional writes
Without loop prevention, external write-back can trigger a new event that triggers the same write-back again.
Anti-pattern 4: Pretend the retention window is infinite
Salesforce stores CDC and platform events for 72 hours. Any outage or backlog beyond that requires backfill and reconciliation.
Anti-pattern 5: Ignore Salesforce API request limits until production
Salesforce returns errors when calls exceed request limits. You need throttling and monitoring from day one.
Comparative architectural matrix
| Decision point | CDC | Platform events | Polling |
| Primary purpose | Record change capture | App-defined events and integration messaging | Periodic state sampling |
| “Real time” fit | Strong for near real time record sync | Strong for event-driven integration | Weak, depends on interval |
| Replay support | Pub/Sub durability inside retention window | Pub/Sub durability inside retention window | Not replay, only re-read current state |
| Drift protection | Requires reconciliation beyond retention | Requires reconciliation beyond retention | Can detect drift if designed, but higher API cost |
| API limit pressure | Moderate (depends on downstream writes) | Moderate (depends on downstream writes) | Often high due to repeated reads |
Concrete failure walkthrough (end to end)
This walkthrough is intentionally concrete and includes specific failure boundaries.
Scenario: A Titan Web portal collects an update for a Salesforce Contact, and an external system also edits the same Contact field during the same minute.
- A user submits a portal form. Titan Push integration is configured to update a Salesforce object via field mapping.
- Titan writes to Salesforce, which triggers a CDC event for the Contact change.
- A subscriber receives the CDC event and attempts to write the update to an external system.
- The external system write times out. The integration retries.
- The retry causes a duplicate attempt. Without idempotency and deduplication, the external system can apply the same change twice.
- During the retry window, a different change is made in the external system to the same field, then written back to Salesforce.
- Now Salesforce has two competing updates, and CDC emits further events.
- If loop prevention is missing, each write-back triggers new CDC events and the two systems repeatedly overwrite each other.
- If the subscriber is down for more than 72 hours, the CDC events are purged and cannot be replayed from the event bus. The system must backfill and reconcile from authoritative state.
- If API limits are exceeded during catch-up, Salesforce returns limit errors and the catch-up stalls unless throttling and backpressure exist.
What this walkthrough proves: idempotency, deduplication, conflict resolution, loop prevention, retention-aware replay, and throttling are correctness requirements.
Fully worked example: conflict + replay + reconciliation
This example is designed to be copyable into design docs.
Setup
- System of record: Salesforce is system of record for Contact core identity fields.
- Conflict policy: Salesforce wins for Email, field ownership and merge for Phone.
Timeline
- T0: Salesforce Contact C-001 has Phone = 111.
- T1: External system updates Phone = 222 and publishes a platform event write-back request. Pub/Sub API supports publish and subscribe patterns for platform events.
- T2: Salesforce user updates Phone = 333 directly in Salesforce. CDC emits a change event.
- T3: Subscriber receives events out of order. The system detects that two updates exist inside a short window.
- Conflict resolution: Because Phone uses field ownership and merge, the system applies the policy: last write wins for Phone, but with a guard that the write-back must be idempotent.
- Replay: Subscriber crashes, then restarts. Pub/Sub API can retrieve stored events inside the 72 hour retention window to catch up.
- Reconciliation: A nightly reconciliation job queries Salesforce for C-001 and compares external state. If external state is 222 but Salesforce is 333, reconciliation corrects external to 333 because Salesforce is system of record for Contact.
What this example encodes
- Conflict policy is explicit and testable.
- Replay is bounded by the retention window.
- Reconciliation is required to correct drift and missed events.
How Titan supports Salesforce-first bidirectional sync
This section is limited to mechanisms Titan documents explicitly.
Salesforce as system of record
Titan’s Salesforce integrations are designed to link Titan inputs to Salesforce data and update or retrieve Salesforce records directly via configured Push and Get actions.
Real time propagation patterns aligned to Salesforce events
Titan supports Salesforce platform events inside Titan’s Salesforce integration, including publish and subscribe actions, and it references Pub/Sub API usage as the gRPC mechanism for publishing platform event messages and receiving final publish results.
Reduced duplication and drift
Titan supports reusable integration configurations via cloning Push and Get integrations, which helps standardize mapping and reduce configuration drift across projects.
Titan also supports metadata refresh to clear cached Salesforce metadata and pull the latest object and field definitions for mapping.
Permission-aware operations and auditability
Titan Flow provides a no-code Salesforce Action node where admins configure conditions, mappings, and variables for Salesforce actions.
Monitoring and controls for reliability
Titan provides logs and usage reporting that can support operational monitoring:
- Monthly Usage Logs include API usage and document generation usage.
- Project usage views show how much data each project and process accounts for, including submission counts.
Bidirectional sync evaluation checklist
- What is the authoritative system of record?
- What is the ownership model per object and per field?
- How do you implement idempotency and deduplication?
- How do you prevent write-back loops?
- How do you handle missed events and replay inside the retention window?
- How do you backfill and reconcile beyond the retention window?
- How do you stay within Salesforce API request limits?
- Where is the audit trail stored?
- What monitoring and alerting exists for lag, retries, and dead letter volume?
FAQ
What is real time bidirectional sync?
Real time bidirectional sync is near real time propagation of changes between two systems in both directions, with guarantees around deduplication, retries, ordering strategy, and conflict resolution.
What is Salesforce Change Data Capture?
Salesforce Change Data Capture publishes change events for create, update, delete, and undelete, and it is used to synchronize corresponding records in an external data store.
What are Salesforce platform events?
Salesforce platform events are integration messages used to connect processes between Salesforce and external systems using publish and subscribe patterns. Pub/Sub API is one mechanism for external clients.
How do you handle duplicate events in data sync?
You handle duplicates by designing idempotent consumers and deduplication rules so reprocessing the same event does not create incorrect writes. This is mandatory in event-driven integration where replay and retries are normal behaviors.
What is idempotency in integrations?
Idempotency means an operation can be applied multiple times without changing the result beyond the first successful application.
How do you resolve conflicts in bidirectional sync?
You define a deterministic conflict resolution policy, such as Salesforce wins, last write wins, or field ownership and merge, and you test it using replay and reconciliation scenarios.
What are Salesforce API request limits and why do they matter?
Salesforce enforces API request limits and returns errors when calls exceed a limit. Rate limiting and throttling are required for reliability and correctness.
How does Titan support Salesforce-first integration?
Titan supports Salesforce-first integration by providing no-code Salesforce Push and Get integrations for updating and retrieving Salesforce records, along with platform events integration capabilities and operational monitoring via usage logs.
Disclaimer: The comparisons listed in this article are based on information provided by the companies online and online reviews from users. If you found a mistake, please contact us.
You might be interested in
Writing Your First Notarized Letter Like a Pro
How to Remove Track Changes in Word
Signee Vs. Signer Vs. Signatory: What are They?
All-in-One Web Studio for Salesforce