A retry can create a duplicate order or invoice. Specify business processing state as well as network behavior, including identifiers, retries and exception handling.
Ask what happens when the same request is retried. A sender can receive an error after the receiving system has completed processing. The design needs a way to recognize the same business request and determine whether it already completed.
What the official documentation establishes
Pub/Sub documents that publish-side duplicates can result in multiple message copies even when exactly-once delivery is enabled. Transport guarantees and business-level deduplication need separate review.
Google Cloud: Exactly-once delivery
The following are For f design and review recommendations. They are scoping considerations, not customer results or a guarantee of outcomes.
Separate transport identifiers from business identifiers
An identifier regenerated on each attempt may not distinguish a retry from a new order. Define the business request unit and a stable identifier for repeated attempts. Agree whether updates, cancellations and reposting are distinct operations.
Represent partial failures as explicit states
Define states such as received, processing, completed and needs review, with transition rules. If a record was saved but notification failed, retain enough information to retry the right step. Make partially completed actions visible across systems.
Test cases that cannot be resolved by retrying
Exercise outages, expired credentials, schema changes and lost responses. Agree retry limits and intervals, escalation conditions and manual-operation permissions. Acceptance should detect permanently stuck work as well as duplicate execution.
Example: when only an order response is lost
Consider an order that was registered successfully while the sender timed out. Sending it as a new order can create a duplicate, so provide a way to query the outcome using the original business ID. If the same ID arrives with different contents, flag it for review instead of silently overwriting it. Distinguish registered, not registered and unknown outcomes, and include the interface or procedure for investigating unknown outcomes in the scope.
Test simultaneous sends, updates and cancellations arriving out of order, and manual actions during retries. Success means business records reach their intended counts and states and remaining exceptions are traceable, not merely that no error appears. If the receiving system cannot expose processing results, agree on the achievable guarantees and reconciliation work under that constraint.
Deliverables to agree before engagement
| Area | What to review | Evidence to retain |
|---|---|---|
| Identification | How repeated requests are identified | Business identifiers and retry rules |
| Recovery | Handling partial completion | State model, retry and manual handling |
| Validation | Differences between sender and target results | Register of missing, duplicate and inconsistent results |
Prepare for an initial conversation
- Define business operations, including updates and cancellation
- Review the target API and retry conditions
- Scope diagnostic records and manual-recovery interfaces
What if the receiving system has no deduplication support?
Assess what can be covered by reconciliation and state tracking. Some conditions, such as an unverifiable receiver outcome, prevent a complete determination. State those limitations and manual procedures in the proposal.
Discuss the scope with For f
Explore the related service / Review the approach and scope
References and verification date
Official page last updated: 2026-09-18. Information checked: September 21, 2026. Product features and conditions can change; check the official documentation and your environment before implementation.
The thumbnail is an AI-generated concept image, not an actual system screen or measured result.