Your Systems Don't Talk to Each Other. Here's How Integration Actually Works

Integration is not really about connecting software. It is about deciding which system owns each fact in your business, and then moving changes between systems reliably even when one of them is down, slow, or wrong. Teams that skip the first half go straight to writing connections and produce something that works in a demonstration and fails quietly in production — usually by making two systems disagree while both look confident.

Key Takeaways

• Decide which system owns each fact before writing any connection. Two systems that both “own” stock levels will disagree, and no amount of syncing fixes it.
• Four patterns cover almost everything: scheduled files, direct database access, point-to-point APIs, and a message queue.
• Point-to-point connections multiply. Six systems fully connected is fifteen relationships, each of which can break independently.
• Assume every message will arrive twice and every remote system will be unavailable. Designs that assume otherwise fail in their first bad week.
• Reconciliation is not optional. Without a routine that compares both sides, you find out about drift from a customer.

The question to answer before anything else

For every important fact your business holds — a customer’s address, a product’s price, a stock level, an order’s status — exactly one system must be the authority. Everything else holds a copy.

This sounds obvious and is routinely violated. Stock is edited in the warehouse system and in the online store. Customer details are updated in the CRM and in the accounting package. Both are “live,” so both are trusted, and eventually they disagree. At that point no synchronisation strategy can help you, because the systems are not out of sync — they are both right about different things, and nobody decided which one to believe.

Write this down as a table before designing anything: each fact, its owning system, and which systems hold copies. Half the difficulty of most integration projects disappears at this step, and the arguments it triggers are the arguments you want to have early.

The four patterns

Scheduled file exchange

One system writes a file, another reads it on a schedule. Old, unfashionable, and still the correct answer more often than people admit — particularly with legacy systems, external partners, or high-volume overnight reconciliation.

It is simple, easy to inspect, and easy to re-run when something goes wrong. Its limitation is freshness: data is as current as the last run. If a daily or hourly view is genuinely enough, this pattern will cost less and break less than anything more sophisticated.

Direct database access

One system reads or writes another’s database. Tempting, because it is quick.

Avoid it wherever you have a choice. You are coupling to an internal structure the vendor may change without warning, bypassing the validation rules built into the application, and creating a dependency nobody documents. Direct database writes in particular can corrupt data in ways the owning application cannot detect. Treat this as a last resort for systems that genuinely expose no other interface.

Point-to-point APIs

Each system calls the other directly over a defined interface. This is the modern default, and for a small number of systems it is the right answer: clear, direct, and reasonably easy to debug.

Its weakness is arithmetic. Connecting three systems takes three relationships; six takes fifteen. Each is a separate piece of code with its own authentication, error handling, and failure modes, and each has to be updated when either end changes. Point-to-point is excellent at small scale and becomes the thing everyone complains about at medium scale.

A message queue in the middle

Systems publish events — “order placed,” “stock adjusted,” “customer updated” — to a shared queue, and interested systems subscribe. Nothing calls anything directly.

The benefit is that adding a seventh system does not require touching the other six, and a system being temporarily down does not lose messages; they wait. The cost is a new component to run and monitor, plus genuinely harder debugging, because tracing what happened means following a message through several independent consumers. Worth it when you have several systems and real volume. Overkill for connecting two.

The questions that choose the pattern

How fresh does the data need to be? Be honest. “Real time” is expensive and often unnecessary — much of what businesses describe as real-time is comfortably served by a five-minute cycle. Ask what actually goes wrong if the data is fifteen minutes old, and cost the answer.

What happens when the other side is unavailable? It will be. Does the operation queue and retry, fail loudly, or fail silently? Silent failure is the worst outcome and the most common default. Decide this deliberately for each connection.

What happens when the same message arrives twice? It will. Network timeouts and retries mean duplicates are normal, not exceptional. Every operation that changes data needs to be safe to repeat — processing the same order twice should produce one order, not two. This property is worth designing for from the start.

Who resolves a conflict? When both sides changed the same record, something must decide. Last-write-wins is a choice, not a default, and it is sometimes the wrong one.

What separates a working integration from a fragile one

Fragile integrations are the ones that only work when everything else is working. The difference is a handful of unglamorous properties.

Retries with sensible backoff, so a brief outage does not become lost data. Comprehensive logging of what was sent and what came back, because integration bugs are almost impossible to diagnose from the result alone. Alerting that reaches a person when the failure rate rises, rather than a log nobody reads. And reconciliation — a scheduled routine that compares both sides and reports differences.

Reconciliation is the one most often skipped, and it is the one that determines whether you discover a problem yourself or hear about it from a customer. Even a simple nightly count comparison catches drift early.

A sensible starting sequence

Start with the one connection that removes the most manual work, usually whichever data someone currently re-types between two systems. Get it working end to end, including its failure handling and a reconciliation check, before adding a second.

Resist connecting everything at once. Each connection you add multiplies the ways the whole can fail, and a business that has learned to trust one integration is in a much better position to add the next. If you find yourself planning the fifth or sixth connection, that is the moment to consider a queue rather than more direct links.

This work is also a prerequisite for a good deal else. Automation and AI projects stall on exactly this ground — an AI agent cannot act on your systems if those systems have no reliable interface to act through.

Frequently asked questions

Our vendor says they have an API. Is that enough? Not by itself. Ask what it covers, its rate limits, whether it supports the writes you need, whether it can notify you of changes or only answer questions, and whether the vendor versions it. A read-only API with a low rate limit is a very different proposition from a complete one.

Can we just export to spreadsheets? As a stopgap, yes, and it beats manual re-typing. It is not integration, because there is no reliable failure handling and no reconciliation, but it is an honest interim step while a proper connection is built.

How long does a typical integration take? The connection is rarely the long part. Agreeing which system owns which fact, handling the error cases, and testing against realistic bad data usually take longer than the code that moves the record.

What about middleware and integration platforms? They can genuinely help, particularly for common systems with ready-made connectors. They do not make the ownership question go away. A platform will happily synchronise two systems that disagree about who owns the truth, faster than before.

The next step

Draw your systems on one page, then draw an arrow for every piece of data that currently moves between them — including the ones a person moves by re-typing. Mark which system owns each fact. Most businesses find one or two facts with no clear owner, and those are exactly where the problems have been coming from.

Want the map drawn properly? ZAWAT does integration and support work for businesses across Oman and the GCC — connecting ERPs, payment gateways, WhatsApp, and the systems you already own. Request a call to talk it through.