Distributed Application Architecture Patterns

8.4 Claim Check

Reduce message sizes by storing large payloads externally

This pattern is based on Claim Check by Hohpe et al. [4, p. 305, 137] and Microsoft [138].

8.4.1 Context

Two parties need to pass messages with data payloads through a network, messaging system or other services. None of these intermediaries need to access the payload, and at least one of the following holds.

8.4.2 Solution

Add a data store that is accessible to both communicating parties. The producer stores the payload in the store with an associated unique key – the claim-check token. It then sends the message with the token instead of the payload. Upon receiving the message, the consumer uses the token to retrieve the payload from the store (see fig. 23).

Figure 23: Claim Check

The system can also conditionally store the payload based on the size, content, or other criteria to minimize round-trips to the data store if it is not necessary.

8.4.3 Potential issues

Failures may make payloads pile up in the storage system. Strategies for garbage collection or time-to-live need to be defined. The storage system can also become a bottleneck or a single point of failure if additional measures are not taken.

This pattern may also require tuning to find the balance between throughput and latency and introduce additional complexity into the communication.

8.4.4 Example

ExampleEshop messaging queues to handle review processing. However, the reviews can contain large files, such as images or videos, which overwhelm the messaging system during large events. To address this, the system saves the files to a separate data store before adding the message to the queue. The message only contains a reference to the file, which allows the system to handle much larger backlogs.