Imagine a paid service request that should create one operational task. The payment notification arrives, the task is created, and the connection breaks before the sender receives a response. A second notification arrives. Should the system create another task?
This hypothetical example is useful for reviewing integrations because both deliveries can be legitimate. It is not a description of OVZA’s implementation. The question is how the workflow distinguishes another delivery attempt from another business action.
Write the business rule before the handler
For our example, I would begin with: “One confirmed purchase creates one preparation task.” That is the invariant: a condition that should remain true even when messages are repeated or processing is interrupted.
Idempotency means a repeated request can be handled without producing additional unintended effects. AWS’s discussion of safe retries explains why an explicit request identifier is more reliable than assuming that identical parameters always mean the same intent. AWS on idempotent APIs.
For a service company processing Arabic and English requests, the reference should identify the purchase, not the translated service label or email subject. The same customer may legitimately buy the same service twice. Our rule must allow that while preventing duplicate preparation for one purchase.
Learn the provider’s delivery contract
Before implementing the receiver, read what the provider promises. Stripe, for example, documents retries, possible duplicate events and delivery without a guaranteed event order. It also requires verifying the origin of webhook events before acting on them. Stripe webhook documentation.
Those details are an example, not a claim that every regional gateway behaves identically. For a different provider, check its event identifiers, authentication mechanism, retry behaviour and available lookup API. If the documentation leaves a gap, record it as an integration question.
Then decide what acknowledgement means in our system. A successful response should follow durable acceptance of the event or completed processing according to the design. Returning success while holding the only copy of unfinished work in memory leaves a recovery problem if the process stops.
Separate accepting work from completing it
I would review the gap between recording the business change and notifying another service. A database update can succeed while an email or external task request fails.
One possible design is a transactional outbox: save the business update and a pending-message record together, then let a separate worker deliver the message. This addresses a two-write consistency problem; consumers still need to handle duplicates. AWS transactional outbox guidance.
That pattern adds a worker, retry state and monitoring. A small workflow may need a simpler durable queue, while another platform may already provide the required mechanism. Choose based on the failure you need to recover from and the infrastructure the team can actually operate.
Treat uncertain outcomes as their own case
Suppose the external task API times out after receiving our request. “No response” does not tell the employee whether a task exists. Retrying with a fresh identity may create another one.
Where supported, reuse the same idempotency key for retries of that particular operation and follow the provider’s retention and parameter rules. Stripe’s API documents such a mechanism for its own requests. Stripe idempotent requests.
For our example, I would provide an “outcome unknown” state until the system can reconcile the request with the external service. If lookup or safe retry is unavailable, a controlled manual check may be necessary. The employee needs a specific recovery action, rather than a button that blindly starts the whole workflow again.
Test the interruptions you designed for
My review set for this hypothetical workflow would include a repeated delivery after success, two deliveries arriving together, an older event arriving after a newer one, and a process stopping after the external task was created.
For each case, inspect the business record and the task count as well as the response code. Record enough information to connect an event, a purchase and an attempt, while keeping unnecessary personal details out of logs. Check who can see and trigger recovery.
The useful outcome is a system whose operators can distinguish “waiting,” “completed” and “needs investigation.” That clarity matters as much as the happy-path integration. Get in touch if your team needs a developer who follows these operational questions through to implementation.
Frequently asked questions
Why might an integration event arrive more than once?
A sender may retry when it cannot confirm delivery. The receiving workflow should recognise already-processed events before repeating a business action.
Is preventing duplicate emails enough?
No. Check every consequential action, including records, payments and status changes. Define which operations can be retried and which need investigation.