How systems should talk to each other, without the jargon

Integration gets discussed in vocabulary that obscures a simple set of choices. There are four common patterns, and the difference between them is mostly what happens when something fails.

Point to point

System A talks directly to System B. Quick to build, obvious to understand, and the reason most estates eventually become unmaintainable.

The arithmetic is unforgiving. Ten systems that each need to talk to each other is potentially forty-five connections, each with its own error handling, credentials and change schedule. Replace one system and you rebuild nine integrations.

Reasonable for a small number of stable connections. Dangerous as a default, because nobody notices the moment it stopped being reasonable.

Through a hub

Everything connects to one middle layer that handles routing, translation and error handling. Costs more to set up, and pays back the first time a system is replaced — the change is one piece of work rather than nine.

It also gives you one place to see what is flowing, retry what failed, and enforce the rules. The risk is that the hub becomes a bottleneck if every change has to queue for one team, which is an operating model problem rather than a technical one.

Events

A system announces that something happened — an order was placed, a work order was closed — and anything interested reacts. The announcing system does not know or care who is listening.

This suits situations where one thing happening should cause several others, and where you want to add a new consequence later without modifying the original system. It is harder to trace when something goes wrong, so the monitoring has to be designed rather than added.

Files

Still everywhere, still legitimate. A file is produced on a schedule and picked up by something else. Simple, well understood, and appropriate for large batches and for systems with no other door.

The weakness is timing and silence: a file that did not arrive is only noticed if something is checking. Most of the failures we are asked to investigate in file-based integration are absent files nobody was watching for.

The part that actually matters

Whichever pattern you choose, the same four questions decide whether it survives:

What happens when the other end is down? Retry, queue, or fail — decided deliberately, not left to a default.

Who gets told when it fails? A person, not a log file.

Can you replay what was missed? After an outage, the gap has to be fillable.

What happens when the same message arrives twice? If a duplicate creates a duplicate record, the integration will eventually cause a problem that is much harder to clean up than it was to prevent.

Most integration failures we see are not the wrong pattern. They are the right pattern with none of these four designed.