Webhook Queue Backlog and Duplicate Processing
A marketing team uses a Fusion scenario triggered by a custom webhook to process new leads from a landing page. The webhook receives about 500 requests per hour during peak times. The scenario first checks if the lead already exists in the CRM (using a search module), then creates a new record if not found. Recently, the team noticed that some leads are being created twice, and the scenario execution history shows occasional 'Queue processing' delays of up to 15 minutes. The webhook is configured with the default settings. The team wants to ensure no leads are lost and no duplicates are created.
1. What is the most likely cause of the duplicate leads, and how would you address it?
Read the worked answer
The duplicates likely occur because the webhook may deliver the same request more than once (e.g., due to retries or network issues), and the scenario does not have idempotency handling. The default webhook settings do not guarantee exactly-once processing. Additionally, if the scenario processes multiple webhook calls in parallel (which can happen when the queue backs up), two executions might both search for the lead and not find it, then both create it. To address this:
- Enable 'Sequential processing' in the webhook settings to ensure requests are handled one at a time, preventing race conditions.
- Implement idempotency by using a unique identifier from the webhook payload (e.g., lead ID) and checking if it was already processed. This can be done by storing processed IDs in a data store or using a unique constraint in the CRM.
- Consider using a 'Queue' or 'Data store' to deduplicate before processing.
- Alternatively, use the webhook's 'Max requests per minute' setting to throttle and reduce parallel processing, but sequential processing is more direct.
2. The team reports that during peak hours, some leads are not processed at all. What could be the reason, and what configuration changes would you recommend?
Read the worked answer
Leads may be lost if the webhook queue overflows or if the scenario errors out and the webhook does not retry. By default, Fusion webhooks have a queue limit (e.g., 1000 requests) and if exceeded, new requests are rejected. Also, if the scenario fails, the webhook does not automatically retry unless configured. To mitigate:
- Increase the webhook queue size if possible (in webhook settings, set 'Queue size' to a higher value).
- Enable 'Retry' in the webhook settings with a suitable number of attempts and delay.
- Ensure the scenario handles errors gracefully (e.g., using error handlers) so that failures don't drop the request.
- Consider using a 'Webhook response' module to acknowledge receipt quickly and process asynchronously, but that may complicate.
- Monitor the webhook queue length and set up alerts.
- Alternatively, switch to a polling trigger (e.g., watch leads in the landing page platform) if webhooks are unreliable, but that may introduce latency.