Replay vs Redelivery vs Reconciliation

Scenario

An order did not appear in the ERP after an outage, and the team is deciding whether to retry the old event or fetch the current Shopify order.

Operational problem

Replay can be useful, but an old payload may no longer represent the current source state and may duplicate side effects that partially succeeded.

Incorrect implementation

• Bulk replay an outage window without checking partial state.
• Treat redelivery as proof that only one downstream processing attempt can happen.
• Use an old payload when current Shopify state is the safer source of truth.

Safer implementation

• Use redelivery for failed HTTP attempts after endpoint repair and idempotency checks.
• Use replay only when the payload is still valid and side effects are safe.
• Use reconciliation when current Shopify state is more important than the historical event payload.

Evidence and observability

• Original event, attempts, and failure reason.
• Operator, timestamp, and reason for recovery action.
• Final source and downstream state verification.

Recovery decision table

Timeline example

• 10:00: Shopify order event is delivered and recorded.
• 10:01: Downstream endpoint times out after starting ERP work.
• 10:05: ERP contains a partial order header but no line items.
• 10:10: A broad replay would risk a duplicate order header.
• 10:15: Current-state reconciliation repairs the partial ERP record and verifies Shopify order state.

Recovery-selection flow

• If no event was ever generated or delivered, recover from current Shopify state rather than replaying.
• If Webhook Guard has a failed downstream attempt and no side effect occurred, redelivery can be appropriate after endpoint repair.
• If a historical payload is still valid and the operation is idempotent, replay may be safe.
• If source state changed or partial side effects exist, prefer reconciliation.

Minimum evidence before replay

• Original event ID, topic, payload age, and affected business object.
• Last confirmed delivery and processing stage.
• Existing ERP, OMS, WMS, inventory, fulfillment, refund, email, and shipping-label side effects.
• Idempotency key or duplicate-prevention control for the business operation.
• Operator, reason, and verification plan for the recovery action.

Do not replay stale payloads blindly

Replay repeats historical data. When payment, fulfillment, cancellation, inventory, or customer state may have changed, current-state reconciliation is usually safer than replaying an old payload.

Pipeline context

Text equivalent: diagnose the event from source action, subscription, provider delivery, intake, routing, downstream delivery, customer processing, and final business state.

Related playbooks

Product visibility

Sources and last verification