Work Queues
Queue fundamentals
Work Queues decouple data acquisition from processing and give you load balancing, status tracking, and retry semantics. Know the item statuses: New, In Progress, Completed, Exceptioned, and Deferred. Items are added to a named queue with key fields and a priority; a process gets the next item with 'Get Next Item', works it, then marks it Completed or Exceptioned.
Deferral and retry
Deferring an item returns it to the queue with a time delay so it can be retried later - this is the standard mechanism for transient failures. Know that deferred items reappear after their defer-until time and can be picked up again. The trap is deferring Business Exceptions, which will simply fail again forever; those should be marked Exceptioned.
Item keys and duplicates
Queues can enforce unique item keys. If you add an item whose key already exists, the behaviour depends on the duplicate-handling setting - it may be rejected or allowed. Questions test whether you understand that duplicate keys prevent double-processing of the same case, and that key design matters (a stable business identifier, not a timestamp).
Queue design and reporting
Good queue design includes meaningful tags, priorities, and status reporting. Understand the difference between the queue and the collection used to load it. Control Room shows queue contents, statuses, and exception reasons - useful for operational monitoring and for re-queueing exceptioned items after a fix.
Worked example
An invoice process loads invoices into the queue with the invoice number as the unique key. Each session gets the next item, attempts processing, and on a transient system failure defers the item for 30 minutes with a reason. After a bounded number of deferrals, it marks the item Exceptioned so a human can review. Business validation failures are marked Exceptioned immediately with a clear reason.
Traps
Assuming a deferred item is lost (it is not), and using queues as a substitute for proper exception classification.