Callback

Overview

Callback is an asynchronous invocation or message sent after another operation reaches a relevant event or result. It is used to let a provider notify an application without keeping the original request open. It differs from polling, where the application repeatedly asks for status instead of receiving a pushed update.

A typical implementation works as follows: The originating system stores the callback target and correlation data, performs the underlying work, then invokes the receiver with an event or result. Recovery for Callback should combine replay controls with an authoritative status check rather than trusting delivery history alone.

Common risks include callbacks can arrive late and more than once. Important failure modes include callbacks. These failures can arrive late, more than once, out of order, or after the receiver has changed state, and the sender may not know whether a timeout completed.

Core controls require teams to authenticate messages, use durable correlation and idempotency, acknowledge quickly, model state transitions, and reconcile uncertain outcomes. Business actions triggered by Callback should be idempotent and should verify the current object state before fulfillment or accounting updates.

Operational evidence should include callback ID, triggering operation, target, event type, payload version, attempt history, acknowledgment, and processing result. Callback should be documented alongside Callback Event, Callback Handler, and Callback URL.

Monitoring for Callback should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. Replay of Callback should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event. For Callback, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.