Does queueable interface/class use Flex queues

Question

I have tried to find its answer on multiple places but unable to do so, I know Batch classes use Flex queues and Batch queues. Just wondering what does queueable interface or class use? Does it also use flex queues and batch queues or it uses some other queue?

Answer 1

The Flex Queue is its own unique queue, separate from the asynchronous queue. Basically, until a Batchable process starts, it is in the Flex Queue, and can have its priority changed. Once the system has resources, it starts building up jobs to perform in the asynchronous queue. This includes start, execute, and finish methods of Schedulable, Queueable, and Batchable, as well as future methods. I can't find an official Salesforce page with this image, but several blog posts show this depiction of asynchronous processing:

If anyone can source the appropriate Salesforce page this came from, please feel free to edit this answer.

As you can see, Bulk API, Batch, future (etc) all are in a per-org queue, and they are interleaved. There's a special rule that says that if there are more than 12 asynchronous calls from a single org, another org will get a chance to execute^{[citation needed]}. It appears this may have changed, as the current documentation for @future says:

Avoid adding large numbers of future methods to the asynchronous queue, if possible. If more than 2,000 unprocessed requests from a single organization are in the queue, any additional requests from the same organization will be delayed while the queue handles requests from other organizations.

There's no such thing as different queues for different types of asynchronous processes. Salesforce considers each of these asynchronous calls equally, with some minor caveats (namely, one one Batchable start method may execute at a time per org). There is the Flex queue, and the asynchronous queue, which are two distinct queues in the system.

Generally speaking, asynchronous calls are processed in the order they are received, but if an org has too many items in the asynchronous queue, the queue may be reordered. Also, chaining requests (e.g. Queueable calling Queueable) will impose a minimum delay between executions to give other orgs a chance to execute.

Answer 2

I just got confirmation from Salesforce support on this. When Batchables are added they have a state of Holding at first. Queueables do not and therefore can't count against the limit of 100 in Holding. (They start in Queued.)

If you manage your Batchables instance-wide you won't get that exception no matter how many Queueables you add. Oddly there isn't a governor limit on queueable count at all. There is a limit of 2000 unexecuted futures but that doesn't apply to queueables.

See also this thread.

Answer 3

As per my experience the flex queue is the place where all the queued job stay. It keeps there till the time of any free resource found . Also the job queue can hold 100 after that count all the jobs send for the flex queue.