A network team's receiver opens a ServiceNow ticket for every Catalyst Center event webhook it accepts, and the service desk now sees duplicate tickets for the same assurance alert. The endpoint is slow, so the handler must acknowledge quickly before its ticket work finishes. Which receiver design handles these event webhook payloads correctly?
Select an answer to reveal the explanation.
Short Explanation
You can prevent duplicate tickets by durably recording each event’s instance ID and queueing its ticket work before replying HTTP 200. That quick acknowledgment lets the sender move on while your receiver safely handles the ticket in the background.
Full Explanation
The reliable design separates webhook intake from slower ticket creation: you parse the payload, durably record each new event’s instance ID, queue its ticket work, and then promptly return HTTP 200. This helps prevent duplicate processing while allowing the sender to move on without waiting for the service desk workflow. Creating the ticket synchronously before returning HTTP 200 uses the right identifier and durable deduplication, but a slow ticket system can delay the acknowledgment and fail the quick-response requirement. Deduplicating by instance ID in memory and queueing work before acknowledging is also quick, but a crash or restart can erase the deduplication record or queued work, so accepted events may be lost or processed again. Durably queueing work but deduplicating by alert type acknowledges promptly, yet alert type is not a unique event identifier: separate instances of the same alert type could be mistaken for duplicates. Exam caveat: HTTP 200 confirms receipt, not successful ticket creation, so downstream failures and retries need their own handling. Practical check: replay the same instance ID, send a different instance ID with the same alert type, then restart the receiver and verify that the intended queued work remains recoverable.