Loan Application Queue Backlog
A Blue Prism process handles loan applications by reading a queue. Each case involves: retrieving applicant data from a web form, validating against a legacy system, and updating the core banking system. The process runs every 15 minutes, processing up to 10 cases per run. Recently, the queue backlog grew from 50 to 500 cases in two days. Investigation shows that 80% of cases are being marked as 'Exception' due to a timeout when the legacy system responds slowly. The timeout is set to 30 seconds. The legacy system's average response time is 25 seconds, but during peak hours (10 AM–2 PM), it often exceeds 35 seconds. The process currently runs 24/7 with the same timeout. The business requires all applications processed within 4 hours. The current setup causes many retries, further loading the legacy system.
1. What are the root causes of the backlog, and how would you redesign the process to meet the 4-hour SLA without increasing load on the legacy system?
Read the worked answer
The backlog stems from two main issues: (1) The timeout of 30 seconds is too short for peak-hour responses (often >35s), causing false exceptions. (2) The process retries immediately, adding load and worsening response times. To meet the 4-hour SLA, first increase the timeout to 45 seconds to accommodate peak responses. Second, implement a retry mechanism with exponential backoff: on timeout, requeue the item with a delay (e.g., 2 minutes) and limit retries to 3. Third, schedule the process to run more frequently during peak hours (e.g., every 5 minutes) but with a lower batch size (e.g., 5 cases) to avoid overwhelming the legacy system. Fourth, introduce a separate queue for peak-hour items with a longer timeout. Finally, monitor legacy system response times and adjust dynamically. This reduces false exceptions, spreads load, and ensures timely processing.
2. How would you modify the queue configuration and process logic to handle the peak-hour variability?
Read the worked answer
Modify the queue to have two priorities: high priority for items that have failed once due to timeout, and normal priority for new items. Set the process to first attempt high-priority items with a longer timeout (45s). For normal items, use the standard timeout but if they fail, move them to high priority. Additionally, implement a 'defer' mechanism: when a timeout occurs, use Blue Prism's 'Defer' action to requeue the item with a delay of 5 minutes, rather than immediate retry. This reduces contention. Also, adjust the process schedule to run every 10 minutes during peak hours (10 AM–2 PM) and every 15 minutes otherwise, with a batch size of 8 during peak and 10 off-peak. These changes balance load and SLA.