guide 4 min read
How to design product integrations for failure and recovery
Design integrations around ownership, data meaning, partial failure, retry behavior, and visible recovery so an external dependency does not make the workflow ambiguous.
THE SHORT ANSWER
What you need to know
Design an integration as a shared workflow with clear ownership and failure behavior. Define which system is authoritative for each fact, how changes are exchanged, and what happens when an action only partly succeeds. Make uncertainty visible to users and operators. Test interruption, repetition, and conflicting updates before treating a successful connection as a dependable product capability.
Key takeaways
- Define authority for each shared fact.
- Separate requested work from confirmed completion.
- Plan retries and conflict handling explicitly.
- Give users and operators a clear recovery path.
Agree on the meaning and ownership of data
Two systems can exchange the same field name while disagreeing about its meaning. An integration between a class booking product and a venue calendar might treat reserved as a provisional hold in one system and a confirmed session in the other. Define the states and decide which system controls them. Identify stable references so updates affect the correct record. Clarify which direction changes travel and whether people can edit in both places. Without these rules, a technically successful exchange can produce contradictory information that neither product knows how to resolve.
Model partial success and delayed outcomes
An external call can fail, time out, or complete after the product has stopped waiting. Separate the state of the local request from confirmation by the other system. In the venue example, the product might show a pending synchronization state until it has evidence that the calendar accepted the session. Do not show a confident completion merely because the request was sent. Explain what the user can do while the result is uncertain. Consider whether subsequent actions depend on confirmation and whether they should wait, remain provisional, or follow a clearly described alternate route.
Choose retry and conflict behavior
Decide how repeated requests are recognized, which failures can be retried, and when human review is needed. A retry should not create duplicate sessions, and an old update should not silently replace a newer decision. Define what happens if someone changes the venue calendar while the booking product holds an earlier version. The team might ask for review, accept a named authority, or create a visible conflict state. The choice depends on the workflow. Record it clearly and test it; leaving conflict behavior to incidental request timing makes the product unpredictable.
Build a recoverable operational path
Give operators enough information to identify affected records and understand the last confirmed state without exposing unnecessary content. Provide a way to retry or reconcile a specific failed operation with clear authority. Test interrupted delivery, duplicate messages, unavailable service, and conflicting edits. The checklist is to define shared meaning, name authority, track requested and confirmed work separately, choose retries, handle conflicts, and rehearse recovery. Review the integration when either side changes behavior. A dependable capability requires an understandable failure path as well as a successful demonstration of exchanged data.
Rehearse recovery with one affected record rather than only checking overall service status. For a pending venue update, identify the local request, the last confirmed calendar state, and whether a retry represents the same action. Ask an operator to explain the next step using the available information. If they cannot do so safely, improve the state model or diagnostics before broadening the integration’s use.
An integration or ownership change may alter existing records. Plan the data transformation and runtime sequence together so old work retains its meaning during rollout.How to plan product data migrations as workflow changes
Common questions
Should every integration retry automatically?
No. Retry only when the action and failure conditions make repetition safe. Uncertain outcomes or conflicting changes may require a status check or a person’s review first.
What should users see when synchronization is delayed?
Show the last confirmed state, the pending action, and any limits on what they can do next. Avoid implying that external completion is known when it is still uncertain.
How is the authoritative system chosen?
Choose authority from the workflow and accountable role for each fact. Different facts can have different owners, but the rules must be explicit and consistent across the integration.
References & further reading
These primary references support the background. The practical frameworks and illustrative examples are written for this guide.
Prepared with AI assistance. Examples are illustrative; no client results are implied. Read our editorial approach.