claim-check
Claim Check keeps large payloads out of the message channel.
- ReferenceCarries stable identifier, correlation, and content metadata.
- Payload storeHolds content, checksum, rights, and retention period.
- LifecycleConnects delay, retries, expiry, and cleanup.
Context
Why this is important
The smaller broker contract creates a second retrieval path whose security and lifetime must be tested.
The external shipping service is hypothetical; currently seven shop modules run in the same application.
Claim-check contract
The current shop processes its seven modules in a modular monolith. For a hypothetical external shipping service, Invoice creates a PDF, stores it encrypted under an opaque identifier, and sends order ID, object identifier, media type, and checksum through the broker. Shipping retrieves the document using its own service identity. The team delays the message beyond the normal URL lifetime, tests redelivery, and proves controlled renewal plus cleanup only after business completion.
This is how you read the picture
- Reference Opaque identifier rather than public URL
- Payload store Service identity authorizes retrieval
- Lifecycle Delete only after completion evidence
| Comparison | Part | Responsibility | Failure |
|---|---|---|---|
| Message | Identifier, type, checksum | Delivery and redelivery | Reference is missing or invalid |
| Store | Encrypted content and least privilege | Retrievability during retention | Object missing or access denied |
| Cleanup | Completion or retention evidence | Targeted deletion | Premature deletion or orphaned object |
Benefits & limitations
Helps if:
- Documents or binary data exceed the broker limit.
- Receivers need to retrieve content independently again.
- Sensitive payloads should remain outside broker logs.
Boundaries
- Message delivery proves neither availability nor integrity of the external payload.
- Expiry that is too short breaks retries; retention that is too long increases cost and privacy risk.
- A freely transferable URL expands access without control and does not replace service authorization.
In practice
- Store a large invoice document in object storage and send only its reference, order ID, and expiry. Check that the message contains no confidential payload.
- Expire the reference before retrieval and test denied access. Define how the consumer reports the failure and whether secure renewal is possible.
- Compare claim check with an inline message payload by size limit, access control, lifetime, and the added storage dependency.
Read the detailed explanation
The sender stores the content, receives a unique identifier, and sends metadata plus a reference. The receiver authenticates to storage and verifies type, size, and integrity before processing.
Retention must cover message delay and retries; cleanup may occur only after business completion or a defined period. An opaque identifier with server-side authorization limits sharing better than a long-lived public URL.
Asynchronous Communication explains decoupled transport. Delivery Guarantees cover redelivery and acknowledgement; claim check adds secured payload storage.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which data belongs in the message?
View the solution with justification
A stable object identifier, correlation, and type plus integrity metadata.
ApplyingTransferred to a new situation
How does the shop protect PDF retrieval?
View the solution with justification
Shipping authenticates with its own identity; the opaque identifier alone grants no access.
EvaluateWeighing an alternative
What determines retention?
View the solution with justification
Delivery delay, retry window, business completion, and legal requirements.
Explore further
These building blocks continue the thoughts of this page.