Request/Acknowledge

A client would like to manipulate a file or document, launch a business task,
or notify a system about an interesting event. Requests don't need to be
processed right away. If a response is required, it doesn't need to be
delivered as soon as the request has been processed.

How can a web service safeguard systems from spikes in request load and ensure that requests are processed even when the underlying systems are unavailable?

Temporal coupling is considered to be relatively high when a request must
be processed as soon as it's received. The implication is that the systems
(e.g. databases, legacy or packaged applications, etc.) behind the service
must always be operational. If systems have been taken off-line, perhaps
for maintenance reasons, then client requests will be rejected. High temporal
coupling also leaves systems vulnerable to the effect of unanticipated spikes
in request load. Since the capacity of a system (i.e. memory, CPU, disk,
network bandwidth, number of database connections) is usually based
on average loads, a spike can cause excessive resource utilization leading
to systemic failures.

The web service could attempt to mimic the fire-and-forget characteristics
of queues by not returning a response (a.k.a. One-Way or In-Only
message exchange pattern). In this approach, the service receives a
request, processes it, but doesn't provide a response. While this eliminates
temporal coupling and blocking on the client, it doesn't let the client know
whether or not a request has been received and if it will be processed.
It also doesn't alleviate problems related to unavailable resources
(e.g. databases) or request spikes. How then can a web service behave
like a queue while also providing immediate client feedback?

When a service receives a request, forward it to a background process, then return an acknowledgement containing a unique request identifier.

Request/Acknowledge services typically perform the following steps:

Receive request

Authenticate client credentials (optional)

Authorize client for requested operation (optional)

Validate request (optional)

Generate Request Identifier or URI

Store and Forward request

Return an acknowledgement

The Request/Acknowledge/Poll variation on this pattern allows clients to poll for results at their leisure.

Request/Acknowledge/Callback (a.k.a. Request/Acknowledge/Relay) can be used when the status updates or final results for a request must be delivered as soon as possible to one or more recipients. In this variation of Request/Acknowledge, the request processor pushes a Representation or Callback Message to a Callback Service.