Why System Integrations Break After Launch: The Architecture Trade-offs That Determine Long-Term Stability

Most system integrations pass every test before launch and then start failing quietly a few months later. Nobody changed the code. What changed is the volume of data flowing through it, the number of edge cases a vendor's API introduces without warning, and the accumulation of small assumptions that held up fine in a demo but not in daily use. The architecture you choose before go-live is what decides whether a vendor API change six months from now is a two-day fix or a two-week outage.

Three architectures, three different bets

Every CRM-to-ERP, CRM-to-invoicing, or internal-tool-to-everything-else integration is built on one of three underlying patterns, whether or not anyone names it at the planning stage. Each one is a trade-off between what it costs to build now and what it costs to maintain later.

Point-to-point API calls

This is the fastest and cheapest pattern to build: System A calls System B's API directly, handles its own authentication, and manages its own retries. For one or two connections, it's usually the right call, and there's no reason to over-engineer a single sync between, say, a CRM and a billing tool. The problem shows up as connections multiply. Each new system you connect adds its own direct line to every other system it needs to talk to, so the number of connections grows faster than the number of systems. Nobody owns the whole picture, and there's no single place to look when something breaks.

Middleware or an ETL layer

Here, a hub sits between systems: an iPaaS tool, a message queue, or a piece of custom middleware built specifically for this purpose. Systems talk to the hub, not to each other, and the hub normalizes data, retries failed calls, and logs what happened. It costs more to build upfront because something now has to own that hub, but it isolates failures. When a vendor changes a field name or an auth flow, you fix the transformation once, in one place, instead of hunting down every direct connection that touched it.

Event-driven sync

Instead of one system calling another on a schedule, systems publish events ("customer updated," "invoice paid") and anything interested subscribes. This tolerates systems being temporarily offline far better than the other two patterns, and it scales cleanly when several systems need to react to the same change in near real time. It's also the heaviest to build correctly: someone on your team needs to actually understand event ordering, idempotency, and what happens to an event nobody was listening for at the time.

The failure modes that don't show up in testing

• Rate limits: point-to-point connections make their own calls independently with no shared throttling, so real production load hits a vendor's rate limit in a way a test environment never did.
• Schema drift: a vendor adds, renames, or removes a field, and a point-to-point connection breaks silently because nothing validated the incoming data before it was used. A middleware layer with schema validation catches this in one place; event-driven systems are only protected if the event contract itself was versioned.
• Duplicate records: a webhook fires twice, or a failed sync job restarts and reprocesses rows it already synced. This happens across all three patterns, but it's worst in point-to-point, where there's no shared place enforcing an idempotency key.
• Sync conflicts: two systems both write to the same field and the last write silently overwrites the other. A middleware layer can define which system is authoritative for which field; raw point-to-point connections usually only resolve this after it's already caused a support ticket.
• Orphaned webhooks: a subscription outlives the process meant to receive it (an endpoint moved, a secret rotated, a service redeployed), and the vendor either stops retrying or quietly retries into a 404 for weeks before anyone checks. Middleware and event-driven setups tend to have monitoring on this by design; individual webhook handlers built ad hoc often don't.

The real test: what happens when the vendor changes something

The question that actually matters isn't whether an integration works on day one. It's what happens when a CRM or ERP vendor deprecates a field, changes an OAuth flow, or restructures an endpoint, which is a routine event on any actively maintained platform. With point-to-point connections, every direct link touching that field needs its own fix, its own test, its own deployment, and you often don't have a complete list of every place that reads it. What should be a two-day job turns into a two-week outage because the same problem has to be found and fixed in five different places. With middleware, you fix the transformation once, run a regression check against the systems downstream, and you're done. In a properly versioned event-driven setup, the change is isolated to the producer, and consumers keep working on the old schema until someone migrates them deliberately.

This is the same underlying idea covered in The Internal Tool Lifecycle Model: tools don't fail randomly, they fail in predictable phases, and the connective layer between systems is usually the first thing to show wear because it's the part nobody assigned an owner to.

How to tell which pattern you need before go-live

• Count the systems, not the connections: one or two integrations rarely justify middleware; four or more usually do.
• Look at volume and timing: if several systems need to react to the same event within seconds, point-to-point and even simple middleware polling won't hold up. That's an event-driven problem.
• Ask who maintains it after launch: if there's no dedicated person watching integration health, a centralized middleware layer with one dashboard beats scattered point-to-point logic that fails silently.
• Decide field ownership up front: if two systems can both legitimately write to the same field, no architecture fixes that by itself. You need an explicit rule for which system wins before you write a line of sync code.
• Check how often the source systems actually change their APIs: platforms with frequent breaking changes make the cost of point-to-point's scattered fixes much higher than it looks on paper.

When the honest answer is not to integrate at all

Sometimes the maintenance cost of any of these three patterns outweighs the value of automating something a person could reconcile manually a couple of times a week. That's a legitimate conclusion, not a failure to find the right architecture, and it's the same reasoning behind the documented pattern for recommending against building custom software.

If you're weighing what an integration layer would actually look like for your CRM, ERP, or internal tools, that's worth mapping out before any code gets written. Custom Software covers how we scope internal tools against the systems they need to talk to, and AI Integrations covers the same discovery approach when the connection involves an AI-driven workflow rather than a plain data sync. If you're at the stage of estimating cost, the AI Cost Estimator gives realistic ranges once integrations and user counts are factored in.