Sync Loop

A sync loop is what happens when two systems each notify the other of changes: a write into one raises an event, the integration applies it to the other, that write raises an event of its own, and the change echoes back and forth until something stops it. It is the characteristic failure of bidirectional integrations, and it is hard to see coming because every individual hop is behaving exactly as designed. The symptoms arrive before the diagnosis. An audit trail fills with modifications that have no human behind them. A rate limit that was comfortable for months is exhausted overnight. Modified timestamps are refreshed across the whole dataset, so the next incremental query — the one that asks for everything changed since the last run — returns every record instead of the handful that a person actually touched, and the volume problem spreads to every downstream consumer. In the worst version the loop is slow rather than fast, one echo per polling interval, so it looks like ordinary activity for days. Breaking a loop means giving a write a provenance. Stamp changes made by the integration with their origin — a dedicated account, a flag on the record, a marker in the change metadata — and have the listener drop any event whose origin is itself. Compare before writing, so a value that already matches produces no write at all and therefore no event; this single habit removes most loops, because most echoes are no-ops. Where the source exposes a version or revision on the record, act on the version rather than on the fact that something was touched. Then bound it. A per-record ceiling on writes within a window, and an alert on write volume rather than on errors, turn a loop from an incident discovered through a bill or a complaint into one caught on the first pass. The same guard is worth having even in an integration that is nominally one-way, because a one-way sync plus a separate automation on the far side is a loop that nobody designed and nobody owns.