How do you identify integration risks?

Direct answer

What a strong answer covers

How it works

Integration risk hides in the assumptions each side makes about the other. The review walks through every external dependency and asks: who owns it and how do we reach them, what contract and version we depend on, whether the data semantics match ours such as time zones and currency precision, how authentication and key rotation work, what rate, payload, and concurrency limits apply, what availability and latency it promises, whether messages can arrive out of order or twice, how schema changes are announced, whether we can observe failures, and what we do when it is down. Each gap becomes a risk with an owner and a mitigation, tested before go-live rather than during an incident.

Example

The review of a new logistics partner integration found that their API had no sandbox with realistic data, that tracking events could arrive out of order, and that their rate limit of 60 calls per minute was below the projected 90 at peak. Mitigations: a recorded-response test suite, a consumer that orders events by their timestamp before applying them, and a batch endpoint negotiated with the partner before launch.

Common mistakes

• Assuming the partner’s uptime matches ours without reading their SLA.
• Discovering the rate limit from 429 responses on launch day.
• Having no fallback so a partner outage becomes our outage.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.