The integration ticket promised something modest: connect the tracker to the repository, so status flows one way and code links flow back. Two systems, one line between them. The demo passes. A pull request merges, the card moves. Everyone enjoys the magic for a week.
Eight months later, nobody trusts either side. Cards move without merges. Merges land without cards. A quiet script in a folder nobody owns rewrites fields at 2 a.m. according to rules written by an intern who left. Someone asks, in a planning meeting, whether the tracker is real. Nobody says yes.
The ticket said connect two systems. What it shipped was three. The third one, the sync itself, was never on any diagram, never had an owner, never got a test, and has been making decisions for eight months.
The third system, named
A sync is not a wire. It is a system with state, rules, and failure modes of its own, and it deserves to be defined as one: a sync is a third system whose inputs are two other systems' versions of the truth and whose output is a mapping nobody sees until it is wrong.
It carries real responsibilities. Identity: which card is which pull request, decided by IDs, titles, or heuristics, each with its own way of breaking. Conflict resolution: when both sides changed since the last pass, who wins, and what gets overwritten without telling anyone. Completeness: which fields flow, which are ignored, and where partially-synced records go to hide. Failure semantics: what happens on timeout, on duplicate, on a rename at the wrong moment.
None of that is in either of the two systems being connected. All of it lives in the seam. And seams are where ownership goes to die, because the tracker team thinks the sync belongs to the repo team, the repo team thinks it belongs to the tracker team, and both are right, which is why neither is.
This is the same class of silence as What the Spec Doesn't Decide, the Model Will. There, gaps in the spec became decisions taken by the model. Here, gaps in the integration design become decisions taken by the sync layer, at runtime, in both directions, with write access. The conflict rule you never chose has a default. The default is overwriting something.
Why do both sides look fine while the whole is wrong?
Because each system is internally consistent. That is what systems are good at.
The tracker's records all add up. The repository's history is coherent. The disagreement lives only in the mapping between them, and the mapping has no screen, no alert, and no constituency. Nobody checks the third system, because nobody thinks of it as a system. It is "the integration," a noun that hides an entire undocumented subsystem.
The failure is also bidirectional in a way single-system thinking misses. A bug in the tracker corrupts the tracker. A bug in the sync corrupts both, and then repairs itself cosmetically: the next sync pass overwrites the evidence of the last one. Debugging a sync means debugging a system whose state is continually self-erasing. That is why sync incidents take longer than any other kind, and why the honest postmortem usually ends with someone asking why this thing exists.
The cost compounds quietly. Every new field someone wants to flow is not a checkbox; it is a new column in an undocumented schema, with its own conflict semantics. The sync accretes rules the way Most Technical Debt Is Deferred Judgment, Not Bad Code describes systems accreting unmade decisions. Each rule was reasonable on the day it was written. Together they are a program with no source code.
The design rule: derive, do not synchronize
The strongest fix is not a better sync. It is deleting the sync.
If both views can be derived from one store, there is nothing to synchronize. The treemap and the story map in The Roadmap and the Codebase Are Different Trees are the canonical shape: two projections of one hierarchy, zero identity mapping, zero drift. When the tracker is the only system of record and the dashboard is a build artifact regenerated nightly, the third system never gets born. Never Hand-Maintain What the System Can Derive is the same rule one level up: copies drift; derivations cannot.
Agent systems rediscover this the hard way. The evidence field in Agent Conversations Without Contracts Are Faster Confusion exists precisely so the receiving side does not have to reconstruct state from messages, which is synchronization through prose. And Ten Agents Managing Ten Agents shows the multiplication: every manager-worker pair that exchanges state instead of sharing it is another third system, quietly accumulating mapping rules.
When a sync is genuinely unavoidable, two conditions make it survivable:
- One owner, named. A person, not a team. The sync is a system; systems have owners.
- One direction of truth. Data flows from the system of record to the derived views. Bidirectional sync is not harder bidirectional sync; it is conflict resolution, forever, unpaid.
- A visible failure signal. Drift count, last successful pass, records skipped. If the sync can fail silently, it already has.
What this is not
Not an argument against integration. Systems must talk. The claim is narrower and more useful: integration is construction, not connection. Budget it like construction, test it like construction, own it like construction.
Not a case for one giant tool. Monoliths do not solve this; they move the sync inside the process boundary, where it becomes the same mapping rules wearing a database name. The third system is smaller, but it is still there.
And not a claim that all syncs are equal in danger. A nightly one-way export of read-only data is a harmless shadow of the pattern. The dangerous class is bidirectional, field-mapping, heuristic-identity sync between two systems that humans edit. That is the one that eats quarters.
Take-home
- Count the syncs your team runs. For each, answer three questions: who owns it, which side wins a conflict, and how would you know it failed yesterday. Any sync with three silence-answers is an unowned third system already making decisions.
- Before approving the next integration, ask the deletion question first: can the second view be derived from the first instead? Derived views cannot drift, because they are rebuilt, not reconciled.
- If the sync must stay, put its drift count on some screen this week. Silent third systems stay silent exactly as long as nobody can see them.
Related reading:
- What the Spec Doesn't Decide, the Model Will
- The Roadmap and the Codebase Are Different Trees
- Most Technical Debt Is Deferred Judgment, Not Bad Code
- Agent Conversations Without Contracts Are Faster Confusion
- Never Hand-Maintain What the System Can Derive
- Build the Snapshot Before the Dashboard
If your tools are connected but your team has stopped trusting either one, the problem is probably not the tools. It is the unnamed system between them. If you want help replacing reconciliation with derivation before the next quarter disappears into the seam, book a discovery call.
FAQ
Why is syncing two systems so expensive?
Because the sync is not a connection, it is a third system. It holds identity mappings, conflict rules, field translations, and failure semantics that belong to neither side. It needs an owner, tests, and monitoring like any system, but it usually ships as a ticket labeled integration and gets none of them.
What is the alternative to syncing two systems?
Derivation. Keep one system of record and generate every other view from it on a schedule. Derived views cannot drift, because they are rebuilt rather than reconciled. When derivation is impossible, restrict the sync to one direction of truth, give it a named owner, and expose a drift or staleness signal.
Why does bidirectional sync fail quietly?
Because each side stays internally consistent while the disagreement lives only in the mapping between them, where nothing alerts. Worse, each sync pass overwrites the evidence of the previous failure, so the third system continually erases its own debugging trail. Sync incidents run long for exactly this reason.
When is a sync acceptable?
When it is one-way, read-only at the receiving end, owned by a named person, and instrumented with a visible failure signal: drift count, last successful pass, skipped records. The dangerous class is bidirectional field-mapping sync with heuristic identity between two systems humans edit. That class should be replaced by derivation or a single source of truth.