Applications · Implementation study
Keeping two systems in agreement
Integration between an application and the accounting, CRM, or scheduling tools a business already runs, built so that a failed sync is recoverable rather than mysterious.
What the demo shows
The connectors, sync runs, record counts, and conflict entries are fictional sample data with local controls. No external service is contacted and no credentials are involved.
Proposed system flow
- 01Change detected
- 02Idempotent write
- 03Retry with backoff
- 04Reconciled state
01
Decide which system owns each field
Most integration pain is not technical, it is an unanswered ownership question. Before any code, each synchronized field needs a designated system of record, and fields genuinely edited in both places need a stated resolution rule. Last write wins is a decision, not a default, and it is frequently the wrong one when the systems disagree about clocks or when one of them is a human typing and the other is an automated feed. Writing that mapping down, field by field with its owner and direction, converts an unbounded class of future bugs into a document someone can review.
02
Make every write idempotent and every run resumable
Integrations fail midway, and the only safe assumption is that any message may be delivered more than once and any run may be interrupted. Each outbound write carries a stable idempotency key derived from the source record and change, so a replay updates rather than duplicates, and each run records a cursor so it resumes from where it stopped instead of reprocessing from the beginning. Webhook receivers need the same treatment in reverse: verify the signature, acknowledge quickly, and process asynchronously, because a provider that does not get a fast acknowledgement will send it again.
03
Retry in a way that helps rather than amplifies
A remote system returning errors is usually a system under stress, and a fixed-interval retry loop from every client turns that into an outage. Exponential backoff with jitter spreads the load and lets the dependency recover, while a bounded attempt count moves genuinely dead work to a place a person can inspect rather than retrying it forever. Distinguishing retryable failures, timeouts and rate limits, from permanent ones, validation errors and revoked credentials, matters more than the backoff curve itself; retrying a rejected field forever produces noise and never succeeds.
04
Reconcile on a schedule, because drift is inevitable
Event-driven sync misses things: a webhook is dropped, a record is edited during a maintenance window, an operator changes something directly in the other system. A periodic reconciliation pass that compares both sides over a bounded window and reports differences is what keeps small divergences from compounding into a dataset nobody trusts. Surfacing unresolved conflicts and dead-lettered records to an operator with enough context to decide, rather than resolving them silently, is what makes the integration something a business is willing to depend on.
Validation plan
- Replay the same source change and webhook delivery repeatedly and confirm the destination record converges rather than duplicating.
- Interrupt a sync run partway and confirm it resumes from its cursor without reprocessing or skipping records.
- Simulate rate limiting and timeouts from the remote system and confirm backoff, jitter, and a bounded attempt count with dead-lettering.
- Run reconciliation against deliberately divergent data and confirm every difference is reported with enough context for an operator to act.
More in applications
Have a similar problem to solve?
Discuss your project