System integration: patterns, methods, and when you need it

System integration is the practice of connecting separate software systems so they work as one, exchanging data and triggering each other's processes without someone copying information between them by hand. A CRM, a warehouse system, and a billing platform can each run well on their own, but integration is the layer that keeps a single fact, a new customer, a shipped order, a paid invoice, consistent everywhere it needs to show up. The harder part isn't the technical connection. It's agreeing which system owns which piece of information, and what happens the moment two of them disagree.

Why integration decides project cost

Picture an online order. The moment a customer pays, that event has to reach at least three other systems: the ERP needs it for accounting and revenue recognition, the warehouse needs it to pick and pack the right items, and the billing system needs it to update the customer's balance. Miss one handoff and the business feels it fast: a shipment that never ships, revenue booked twice, a customer charged for something nobody fulfilled.

This is why integration rarely shows up as its own line item and then blows the budget anyway. Teams scope the visible feature and treat the connections between systems as a detail for later. In practice the connections are where the real complexity lives: mapping fields that mean different things in each system, handling partial failures, and deciding what happens when the warehouse is offline but the order still has to be accepted. That's true even at MVP scope, where an unplanned integration layer quietly eats the timeline meant for the feature everyone cares about.

The four integration patterns

Point-to-point integration wires two systems directly together, usually a script that pulls data from one and pushes it into the other. It's fast to build for a single connection and the worst pattern to scale, since every new system adds connections to all the others. It still fits a one-off link between two stable systems.

Hub-and-spoke routes every connection through a central hub instead of system to system, so each one talks to the hub once. That keeps connections from multiplying with every new system, which is why the pattern is common in Microsoft- and SAP-centric environments. The tradeoff: the hub becomes a bottleneck for change.

API-led integration puts a layer of reusable, governed APIs in front of each system, so new consumers connect to a stable interface instead of a system's internals. A payment provider is a typical case, the sort of setup behind API integration done well. It's the dominant approach today for connecting SaaS products and cloud-native services.

Event-driven integration has systems publish events, an order placed, a payment failed, to a stream, and anything that cares subscribes and reacts on its own schedule. Apache Kafka is the de facto standard for this streaming layer. It decouples systems well and handles volume gracefully, but gives up strict ordering, so receiving systems must tolerate events arriving late, out of order, or more than once.

How to choose a pattern

Four questions narrow the choice fast.

How many systems are involved? Two stable systems can justify point-to-point. Past three or four, the maintenance cost of direct connections usually outweighs the setup cost of a hub or an API layer.

Latency matters too. A nightly reconciliation between accounting systems tolerates a batch job just fine, but a payment confirmation that has to update inventory right away needs an event-driven or synchronous approach, not a queue on a schedule.

Who owns the endpoints? Integrating systems you control is a different problem from integrating a partner's, where you don't control the schema, the uptime, or the release schedule. That's the position you're in with any multi-tenant SaaS vendor you don't operate yourself. External endpoints push you toward API-led patterns with strict, versioned contracts, because you can't coordinate a breaking change with an outside team.

How often do the systems change? A stable legacy system and a fast-moving product are a bad direct pairing. Point-to-point breaks every time either side changes its data model; a hub or an API contract absorbs that change on one side instead of forcing it onto the other.

Where integration projects go wrong

A handful of mistakes account for most integration projects that run over budget or ship broken.

• No data ownership model. Two systems both act like the source of truth for the same fact, a customer's address, say, and nobody has settled which one wins.
• Syncing everything instead of what matters. Mirroring a whole system field by field is tempting, but every extra field is one more thing that can break. Sync what the receiving system actually uses.
• No idempotency: what happens if the same "order created" event fires twice? Without a duplicate check, it creates two orders instead of one.
• Treating a vendor sandbox as production truth. Sandboxes are usually more forgiving than production: relaxed limits, clean data, no edge cases. Code tested only against one tends to fail for the first time in production.

When teams bring integration to a partner

Plenty of integration work is reasonable to build and own internally, especially point-to-point connections between two or three systems that don't change often. A few conditions tend to push it toward an outside team instead.

Complexity crosses a threshold. Once a system integration project spans several systems, mixes patterns, or needs a hub to stay up while pieces around it get replaced, a wrong design decision gets expensive to unwind. This is where teams doing custom software development, or bringing in software development consulting for an architecture review, earn their cost back, mostly by avoiding rework.

The data is compliance-bound. Integrations touching health records, payment data, or anything under GDPR need audit trails, encryption, and access controls built into the integration layer, not bolted on after an incident.

Retry semantics matter more than they look. A financial transaction that fires twice, or an inventory update lost to a dropped message, costs real money. Teams that build integrations for a living have usually already hit these failure modes and built guardrails; teams doing it for the first time tend to find them the hard way. None of that replaces deciding who owns which fact in the first place. A partner can execute a pattern well; they can't make that call for you.