The integration archetypes nobody names

Most integration projects don't fail because someone wrote bad code. They fail because nobody named the shape of the thing before they started building it. Two people say "we need these systems integrated," they nod, and they turn out to have meant two completely different architectures — one of which is right for the problem and one of which is going to break in year two and cost triple to fix.

So here's the useful move that almost nobody makes up front: name the archetype first. There are only a few of them. Each has its own failure modes, its own cost curve, and its own right-and-wrong situations. Pick deliberately and most of the pain disappears before you've written a line.

Why naming matters

I once spent a long time getting a warehouse system and an ERP to agree on a cheese factory floor, where the two systems drifting apart wasn't a tidiness problem — it was a compliance and cash problem. The lesson from that project, and every one like it, is that the code is rarely the hard part. The hard part is that the integration you built didn't match the integration you needed, and you found out at the worst possible time.

You avoid that by knowing which shape you're building. Here are the four that cover almost everything, plus one special case.

Archetype 1: Request/response

The synchronous one. Ask a question, wait for the answer, act on it. Your app calls an API, blocks until it hears back, and moves on. This is how most people picture "integration" because it's the simplest to reason about.

It's great for reads and for simple actions where the answer is needed right now and the other system is fast and reliable — look up a customer, validate an address, check inventory before you promise it.

It strands you the moment the other system is slow or down. Because you're waiting on it, its bad day becomes your bad day. If you find yourself adding timeouts, retries, and fallback logic around a request/response call, that's a signal the problem actually wanted a different archetype.

Archetype 2: Event-driven

Fire-and-forget. Something happens in System A, it emits an event, and System B reacts whenever it gets around to it. Queues, streams, message buses. Nobody blocks; the two systems are decoupled, so one being slow or down doesn't freeze the other.

This is the archetype that scales, and it's usually the right call for high-volume, "tell everyone who cares that this happened" situations. The cost is that you've traded synchronous simplicity for a set of distributed-systems problems you now have to design for on purpose: what happens when a message arrives late? Twice? Out of order? Not at all? If you can't answer those four questions for your integration, you haven't finished designing it — you've just scheduled the incident for a less convenient hour.

Archetype 3: Reconciliation-based

The most under-used and, in high-stakes data, the most valuable. The premise is humility: don't trust the stream to be perfect. Instead of assuming every event landed correctly, you continuously check that both systems still agree, and you surface the drift you can't automatically resolve.

This is the pattern process manufacturing forces on you, because "close enough" is not an acceptable answer for a lot record or an inventory balance. A reconciliation layer doesn't just move data — it verifies parity, catches the one message in ten thousand that went wrong, and says so clearly instead of silently guessing. Every serious integration between systems of record should have some version of this underneath it, and most don't, which is why so many of them quietly diverge until someone notices the numbers are wrong — usually during an audit, usually out loud.

Archetype 4: Batch / ETL

The unfashionable workhorse. Collect a pile of records, move them on a schedule, transform them along the way. Overnight jobs, nightly extracts, the stuff that's been running since before "real-time" was a marketing word.

Batch is genuinely correct whenever "eventually consistent by morning" is fine — reporting feeds, financial roll-ups, data warehouse loads. It's cheap, it's simple, and it's easy to reason about. The failure mode is using it for something that actually needed to be current: treat a real-time need as a batch job and you get inventory that's always a day stale, or a customer who sees yesterday's status. The mirror-image failure is reaching for streaming infrastructure when a nightly job would have done the whole thing in twenty lines.

The special case: EDI

EDI deserves a mention because it's old, ugly, unavoidable, and doesn't fit neatly in one box — it rides on top of these archetypes rather than replacing them. An 850 purchase order might arrive as an event; an 810 invoice might go out in a batch; the whole thing needs reconciliation so a chargeback doesn't surprise you. If a big customer mandates EDI, you're not choosing whether to do it, only how well. (That's its own post.)

How to actually pick

You don't need a framework. You need four honest answers:

• How much latency can you tolerate? Seconds, minutes, or overnight? This alone eliminates half the options.
• What's the cost of a wrong or duplicated message? If it's a compliance record or a financial posting, you want reconciliation underneath whatever else you build. If it's a marketing sync, relax.
• What's the volume? High volume pushes you toward event-driven; low volume makes request/response perfectly fine.
• Who's on the other end, and how reliable are they? The less you control the far side, the more you design for its bad days.

Answer those before anyone opens an editor, and you'll have named the shape. Skip them, and you'll build whatever felt natural in the first meeting — and find out eighteen months later whether it was the right one.

The bottom line

Integrations aren't all the same problem wearing different logos. They're a handful of distinct shapes, and the expensive mistakes come from building the wrong one confidently. Name the archetype, answer the four questions, and put reconciliation under anything that actually matters. The code was never the hard part.

Trying to figure out which shape your integration actually is before you commit to building it? That's exactly the conversation to start with →.