# Claim Check

> Store the big payload externally, put a retrieval token in the message — pick it up when needed.

- **Category**: Integration
- **Subcategory**: Message Transformation
- **Canonical URL**: https://designpattern.fyi/patterns/claim_check/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Video processing pipeline — uploaded video (2GB) is stored to S3. A ProcessVideo message is published to Kafka with only the S3 object key. Video processor Lambda receives the message, fetches the video from S3 using the key, processes it. Kafka is not overwhelmed with video bytes.





## Trade-offs


### Advantages

- Enables arbitrarily large payloads without broker limitations

- Broker stays lightweight — only carries tokens, not data

- Consumers can defer payload retrieval until processing time

- External store can apply its own access control and lifecycle policies




### Considerations & Drawbacks

- External store adds a retrieval step and dependency

- Payload must be cleaned up after processing — lifecycle management needed

- Latency increases — message + external fetch vs direct payload

- Claim check token expiry or store unavailability blocks consumers







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html)