Integration Patterns
Date: 2026-08-17
How systems that weren’t designed together end up joined. The patterns are point-to-point, hub-and-spoke, bus and iPaaS — and the reason the topic exists is that point-to-point is always the cheapest next step and always the most expensive tenth one.
An integration pattern is a standard topology for moving data between separately built systems — how they connect, and what sits in between.
Why the mess accumulates
Each integration is a rational local decision. The count isn’t.
4 systems, point to point 8 systems, point to point
A ─── B every pair a potential link
│ ╲ ╱ │ n(n−1)/2 = 28 possible
│ ╳ │ a real estate has maybe 20 of them
│ ╱ ╲ │
C ─── D each with its own auth, retry,
field mapping, error handling
6 links and one person who understands it
Nothing in the process ever says no. Every individual link is a fortnight’s work with a clear business case; the twentieth one is still a fortnight, and by then nobody can answer “if we change the customer record, what breaks”.
The four shapes
| Point-to-point | Hub-and-spoke | Event bus | iPaaS | |
|---|---|---|---|---|
| What it is | Each system calls each system | A middleware layer everything connects to | Publish to a stream, subscribe as needed | Hosted hub bought from a vendor |
| Links to maintain | n(n−1)/2 | n | n | n, mostly configured |
| Coupling | Direct, everywhere | Everything to the hub | To the event schema | To the vendor |
| Single point of failure | No | Yes, the hub | The broker, usually clustered | The vendor |
| Who builds it | Whichever team needs it | A platform team | A platform team | Often non-engineers |
| Good for | 2–5 systems, stable | Many systems, one owner, heavy transformation | Many consumers of the same facts | Standard SaaS-to-SaaS with connectors |
| Fails as | Combinatorial mess | A monolith with a queue in front | Nobody knows the flow | A £-per-task bill and logic nobody can review |
iPaaS — integration platform as a service, the Zapier / Workato / Boomi category — deserves naming honestly: it’s genuinely the right answer for low-volume SaaS plumbing, and it’s where business-critical logic ends up living outside version control, untested, owned by whoever set it up.
The decisions inside every integration
The topology matters less than these, which are the same in all four:
Push or pull. Push (webhooks) is fast and loses events when you’re down; pull (polling, scheduled export) is slower and self-healing. Anything financial needs a pull-based reconciliation regardless, because push alone cannot prove completeness — Webhooks.
Where the mapping lives. Their field names are not yours. The translation belongs in one named place per integration — an anti-corruption layer — so their model doesn’t leak into your domain. When their customer_ref becomes your customerId in eleven files, changing providers becomes a rewrite.
Who owns the identifier. Two systems each with their own customer ID need a mapping table with a clear owner, or you get two records for one person. This is the same problem as Identity Stitching, with the same consequences.
Full or incremental sync. Incremental is efficient and drifts; full is expensive and correct. Most stable answer: incremental continuously, full weekly, and alert on the difference — a reconciliation that never reports a discrepancy is usually broken rather than perfect.
What happens when it’s down. Queue and retry, drop, or fail the user’s action. Decide per integration, in advance, and write it down — Graceful Degradation, Message Queues.
Keeping it manageable
- An integration register. Source, destination, direction, owner, what breaks if it stops, and where the credentials live. Unglamorous, and the only thing that answers questions during an incident
- Every integration has a named owner. Unowned integrations are how you discover a system is critical by breaking it
- Log every message with a correlation ID, both sides. “Did it send” and “did they receive” are separate questions and both get asked — Observability
- Version the contract, even internally — Backwards Compatibility
- Set a limit on point-to-point links and treat exceeding it as the trigger for a hub, not a debate to have from scratch each time
- Sandbox credentials in non-production. An integration test that writes to a live order management system is a matter of time — Environments
Where it interacts
- Composable Commerce — a composed stack is an integration estate, and this is the cost the vendor diagrams omit
- Event-Driven Architecture — the internal version of the bus pattern, with the same “nobody knows the flow” tradeoff
- Replatforming — every integration is a thing to re-point, and the register is what stops one being forgotten until month end
- Rate Limiting — their limits constrain your sync design far more often than yours constrain theirs