Choose Stream Execution: Direct Calls, Pools or Parallel Tasks

Use direct calls when the current execution path should continue

FunctionCall invokes the consumer in the current execution path without a queue. In an asynchronous runtime that path can still suspend while awaiting I/O. It does not imply that every operation blocks an operating-system thread.

Inherited links use the owning service default. Make that default visible during review before judging an edge by its local settings.

Use a pool to control worker execution

TaskPool dispatches through a named FIFO worker pool. PriorityTaskPool uses configured priorities when selecting queued work. Queue selection order is not a guarantee that multiple executing tasks finish in that order.

Inspect capacity, admission and shutdown settings in the selected runtime. Do not assume that the diagram alone bounds memory or downstream RPC concurrency. See TaskPool and PriorityTaskPool.

Use independent tasks for intentional fan-out

ParallelCall starts independent work for each message without a shared pool. Use it when that concurrency is intentional and the downstream operation tolerates it. For ordered outputs, model an explicit correlation or ordering step rather than relying on scheduling.

Observe the pool dashboards and repeat tests with cancellation and shutdown while requests are active. Preserve causal trace order without imposing an artificial total order on concurrent branches.

Next steps

Current path → FunctionCall
Named FIFO workers → TaskPool
Priority selection → PriorityTaskPool
Independent per-message work → ParallelCall

Related documentation