Reports block checkout. What do you isolate?

Start with the failure boundary

The slow reporting provider is only part of the problem. A shared pool and queue transfer its slowdown to the critical checkout path. Measure the request time budget, concurrency and traffic by function. Confirm which workers are actually shared.

An architecture decision

1. Separate connection pools or concurrency limits for reports and delivery pricing. Reports can have a smaller cap and a separate queue; order resources should remain available when reporting stalls.
2. Set justified timeouts and bounded queues. When a reporting limit is reached, defer the work or explain unavailability instead of waiting indefinitely.
3. Avoid unconditional retries. They amplify load during a failure; allow only safe operations, with a retry budget and backoff.
4. Define distinct service objectives and measure pool saturation, queue depth, timeouts, rejections and user latency.
5. Test a reporting slowdown under representative load. Reports may lag while checkout meets its agreed objective.

A larger common pool might postpone failure but does not create a boundary. Select actual limits from traffic and tests; the information given cannot justify “40 versus 80”.

Isolate lower-priority work before its failure consumes the capacity needed by critical work.