The relationship outlives every conversation

Why is an integration a promise to keep meeting, and why is the bookmark the hard part?

A protocol handles one conversation. An integration is a relationship that outlives every conversation in it. That breaks the assumption both earlier parts rested on:

• A file read is complete or it is not.
• A request succeeds or it fails.
• But a pipeline that copies a table every hour, forever, has no "complete" state and no "failed" state. It has only a position, and the position is the whole problem.

One thing follows at once. Neither party can hold the relationship in memory, because processes restart, connections die, and the two sides scale independently. Therefore the position must be stored as durable state. Therefore something must own that state, and whoever owns it inherits its failure modes:

• lose it, and you re-read everything;
• corrupt it, and you silently skip data;
• share it badly, and two consumers fight over it.

Every mechanism in this article is a decision about where the position lives and what it is measured in.

The organizational problem

The second thing that appears makes integration hard for organizational reasons, not technical ones. An integration spans two systems that usually belong to two different teams, with different release schedules, different incentives and no shared on-call rota. The technical coupling is small. The organizational coupling is total. A schema change is unpleasant inside one company and nearly impossible to manage across a boundary where the producer has no reason to care.

Who owns the interface

Whether you define the interface or consume someone else's decides most of your failure modes:

Most integration pain comes from this asymmetry. It is easy to miss if you only list mechanisms and not positions.