@TanyaS58

Threads in a Queue Processor are parallel workers on each background node that pull items from the stream and run your activity at the same time. You set their number in the Queue Processor rule, which caps how many items can be handled at once on each node. Each thread usually reads from a stream partition, so true concurrency is limited by partitions multiplied by active nodes. More threads can raise throughput, but they also increase CPU use, database I O, and locking, so watch node health and queue lag. Ordering is guaranteed only within the same partition or key, so if you need strict order use a partition key like case ID and keep thread counts reasonable. Make your activity idempotent and quick because multiple threads can retry after errors. Start with one or two threads, then increase slowly while monitoring success rate, average run time, and dead letter queue counts. Run these on background node types and avoid committing inside loops to reduce contention.