mapAsyncUnordered applies asynchronous work to stream elements with bounded parallelism and emits completed results without waiting for earlier, slower elements. Use it when input order is unnecessary and processing times vary. section 16.1.2 section 16.5
A slow database query or remote request does not hold back faster work: completed elements leave the stage, freeing capacity for new elements. The benefit grows as per-element response times differ more widely. section 16.1.2
Variable-latency service calls
For asynchronous database, HTTP, gRPC, or FTP calls, use unordered processing when later responses may safely arrive first. Keep ordered processing when downstream logic requires the original sequence. section 16.1.2 section 16.5
The diagram shows faster elements leaving the asynchronous stage first, making room for additional work while slower elements remain in flight. section 16.1.2
Operational guidance:
- Choose mapAsyncUnordered for high-variance work only when result order is irrelevant. section 16.1.2 section 16.5
- Consider the external service’s request capacity when raising parallelism. section 16.1.2
- Use async stream stages to pass a prior stage’s element into an external call and process its response in the following stage. section 16.5
