Integrating systems without creating a spider web
Integrations start as a line on a diagram and become the most fragile part of the estate. The difference between a clean integration and a spider web is decided early, by naming who owns each piece of data.
One owner per fact
For every important fact, such as a customer address or a stock level, decide which system is authoritative and which systems receive copies. Duplicate ownership is the root cause of most reconciliation work.
Design for failure from day one
Networks fail, rate limits trigger, and third-party APIs change. Every integration needs retries with backoff, a dead-letter queue for messages that keep failing, and an alert that reaches a human.
Ids should be stable and idempotent writes should be the default, so a retried request does not create a duplicate order.
Observe the pipes
Log every request with correlation ids, track latency and failure rate per integration, and build one dashboard that shows whether data is flowing. Silent integration failures are discovered by customers, which is the worst way.
Common questions
- Should integrations run in real time or on a schedule?
- Real time where a customer is waiting, scheduled where batch is acceptable. Real-time integration is more expensive to operate and only worth it when latency changes the outcome.
- Do we need an integration platform?
- For two or three integrations, direct code is simpler and cheaper. A platform earns its cost when you have many systems and want central monitoring and reusability.
Next step
If this question is live in your business right now, describe the situation and you will get a written view on the options, including whether you should build at all.
Discuss your projectRelated notes
All insightsWhen spreadsheets stop being enough
The signs that a spreadsheet-driven operation needs a real system, and the cheapest first step that is not a full ERP implementation.
ReadCustom softwareHow to justify an internal tool
A simple model for calculating whether an internal tool pays for itself, using hours recovered, error cost and the value of visibility.
ReadCustom softwareDatabase design mistakes that cost years
The modelling errors that are cheap to fix before launch and expensive afterwards: missing keys, storing derived data and treating status as free text.
Read