The client may need to work against the service even when the client is disconnected; for example, when using a mobile device. The solution is to queue up requests against a local queue and send them to the service when the client is connected. Similarly, if the service is offline (perhaps because of network problems or machine crashes), you want clients to be able to continue working against the service. When the service is connected again, it can retrieve the pending calls from a queue. Even when both the client and the service are alive and running, network connectivity may be unavailable, and yet both the client and the service may want to continue with their work. Using queues at both ends will facilitate that.

Whenever it is possible to decompose a business workflow into several operations that are separated in time—that is, where each operation must take place, but not necessarily immediately or in a particular order—it is usually a good idea to use queuing, because it will improve availability and throughput. You can queue up the operations and have them execute independently of each other.

When your business transaction may take hours or days to complete, you typically split it into at least two transactions. The first queues up the work to be completed immediately by initiating an external sequence, and the second verifies the success of the first and compensates for its failure if necessary.

Most systems do not have a constant level of load, as shown in Figure 9-1. If you design the system for the peak load, you will be wasting system resources through most of the load cycle, and if you design the system to handle the average load, you will not be able to handle the peak. But with queued calls, the service can simply queue up the excess load and process it at leisure. This enables you to design a system for a nominal average of the desired throughput, as opposed to the maximum load.