Scaling a Process That Is Bottlenecked on the Target Application
A telecoms provider's order-provisioning process runs on 15 digital workers and processes 9,000 orders per day. The target order management system is a legacy thick-client application with a documented limit of 40 concurrent sessions per server. The process currently opens a new session per order and closes it at the end. Average order time is 4 minutes, of which 3 minutes is waiting for the legacy system to respond. Adding workers beyond 15 has produced no throughput gain and has increased legacy system response times, causing timeouts that now account for 8% of items. The business forecasts a 30% volume increase next quarter.
1. Explain why adding workers no longer helps and identify the true constraint.
Read the worked answer
The constraint is the legacy order management system, not Blue Prism capacity. The evidence is consistent:
- No gain from extra workers. If digital workers were the bottleneck, more workers would add throughput. They do not, which means the downstream system is saturated.
- Rising response times under load. Legacy response time degrades as concurrency rises, which is the signature of a system at or past its capacity.
- 8% timeouts. These are a symptom of contention, not a separate problem. Each timeout also consumes worker time on retries, making the apparent worker shortage worse.
- Session churn. Opening and closing a session per order multiplies connection overhead against a system with a hard 40-session limit. Workers may be spending time queuing for sessions as much as waiting for responses.
The 3-minutes-of-4 wait ratio confirms that worker compute is largely idle; the workers are waiting, not working. Buying or adding workers adds waiters, not capacity. The architect must treat the legacy system's 40-session ceiling and its response curve as the governing constraint, and design around it rather than pushing more load at it.
2. Design a solution to absorb the 30% volume increase without breaching the legacy system's limits.
Read the worked answer
The design must extract more throughput per legacy session rather than adding sessions.
1. Session pooling. Replace open-per-order with a managed pool of persistent sessions held below the 40-session ceiling, with a headroom target (e.g., 32-34 concurrent). Workers check out a session, process, and return it. This removes connection churn and makes concurrency a controlled, measurable quantity rather than an emergent one.
2. Throttle at the source. Introduce a concurrency governor so the number of in-flight legacy calls never exceeds the safe ceiling, regardless of how many workers are active. Back-pressure should slow queue consumption, not cause timeouts.
3. Reduce wait time per order. Investigate whether the 3-minute wait includes fixed delays (screen loads, batch windows) that can be overlapped. Where the legacy system permits, batch or pipeline calls so a worker is not idle during a wait. Even modest overlap raises throughput per session.
4. Shift volume off-peak where business rules allow. If orders need not be provisioned in real time, spread processing across a wider window to flatten the peak against the legacy ceiling.
5. Model the numbers. At 32 concurrent sessions and 4 minutes per order, theoretical throughput is roughly 480 orders per hour; the current 9,000 per day implies the estate is well below that, so there is recoverable headroom once churn and timeouts are removed. Validate with a ramp test.
6. Escalate the structural limit. A 30% sustained increase may exceed what the legacy ceiling can absorb even optimised. Present the capacity curve to the business and the legacy system owner; the durable fix may be an API or a server-side limit increase, which is a business decision with a lead time.