Connecting your systems: integrations that survive real life

For every kind of record — customers, items, prices, stock, invoices — name one system as the owner. Others may read it or hold a copy, but changes start in the owner. Two systems that can both edit the same record will eventually disagree, and nobody will know which is right.

Networks retry. A payment confirmation or an order may arrive twice. Give each message a unique key and have the receiving side ignore one it has already processed. This one habit prevents duplicate invoices, double stock deductions and double charges.

Do not send data directly from a user’s click to another system. Put it on a queue, send it in the background, retry with increasing gaps when it fails, and when it keeps failing, put it somewhere a person will see it. A silent failure is far worse than a loud one.

• Save the change locally first, then send it — never the other way round.
• Retry automatically, but cap the attempts.
• Keep a list of failed messages that staff can see, fix and resend.
• Log what was sent and what came back, so problems can be traced.

Third-party systems change their fields, limits and versions. Keep the mapping between systems in one place, validate what arrives instead of trusting it, and test against the provider’s sandbox before every change. Government and banking connections in particular deserve a test environment of their own.

Moving existing data is a different job from keeping systems in step. Do it as a one-off migration with a dry run, a report of what will change, and sign-off before anything is committed — then switch on the ongoing sync.