Skip to content
mcstack.dev
Blog
· 2 min di lettura

Integrations break: what matters is noticing first

A link between two systems is not a job that ends. You need to know when it stops working, before a customer tells you.

An integration between two systems isn't a job you deliver and finish. It's a living thing that depends on other people's software: an API changes version, a certificate expires, the vendor of the business system updates and moves a field, the password of a service gets changed by someone who didn't know it was used there too.

Sooner or later it stops. The difference between an annoyance and real damage is who notices first.

The worst case

The worst case isn't the link that breaks with an obvious error. It's the one that stops silently: orders stop arriving in the business system on Tuesday, nobody notices because there's nothing to notice, and on Friday a customer calls asking where their delivery is. At that point there are three days of orders to recover by hand, and a person who has to work out which ones already went through and which didn't.

Everything that follows exists to avoid that phone call.

What has to be there

Retry without duplicating. If an order is sent twice, the business system must end up with one document. It's the property that makes retrying after an error safe — without it, every recovery is a gamble.

Automatic retries, with growing pauses. Most failures last minutes: the system at the other end is busy, the network hiccupped. Retrying on its own after a minute, then five, then twenty, resolves the majority of cases without anyone noticing.

A visible queue. Whatever hasn't gone through yet has to sit somewhere you can look at, count and resend. If the failed record disappears, the only way to find it again is to go looking in the source system, by hand.

An alarm on quantity, not just on errors. A single error can be normal. Zero orders imported in six hours on a working day is not, even if no error was logged. That second check is the one that catches silent failures.

Readable logs. Not «Error 500», but which order, which field, which response came back. The difference between fixing it in ten minutes and spending an afternoon guessing.

The question to ask whoever builds it

Just one, and the answer tells you everything: «If this integration stops tonight, who finds out and how?»

If the answer is «we notice when you call us», the integration is half finished. The link that moves the data is the easy part; the part that's worth paying for is the one that tells you, before your customer does, that the data has stopped moving.

Weighing up a similar decision?

You get an answer within one working day. If the project isn't something I handle, I say so straight away and point you somewhere useful.