When you check a coat at a theater, you don't carry the coat to your seat — you hand it over and get a little numbered tag. The tag is tiny and easy to pass around; the bulky coat sits safely in the cloakroom until you redeem the tag on your way out. The Claim Check pattern does exactly this for messages: keep the heavy thing in storage, pass around the lightweight ticket.
The problem
Message brokers love small messages. But real workloads often need to move large payloads — a 20 MB scanned document, a video to transcode, a fat batch of records. Stuffing those into a queue or topic causes real pain. Brokers enforce a maximum message size: Azure Service Bus's Standard tier rejects anything over 256 KB, and Azure Storage queues stop at 64 KB. Big messages also slow the broker down and bloat its memory, and you pay to shuttle the same bytes through the messaging layer on every delivery and every retry. The messaging system was built to coordinate, not to be a file transfer pipe.
Below, a 50 MB video meets a queue that takes 256 KB per message. Predict what the broker does with it. Then pick one of the two workarounds teams usually reach for, and see where it leads.
Both workarounds keep treating the queue as the way to move the file. A bigger limit turns the broker into expensive file storage, and chunking turns every consumer into a reassembly engine. Claim Check takes the file out of the message entirely.
How it works
Split the payload from the message. When the producer has a large payload, it first writes the payload to shared storage — a blob store, object store, or similar — which hands back a key or URL. The producer then puts only that reference (plus any small metadata) onto the queue. That reference is the claim check. The consumer pulls the small message, reads the reference, and fetches the full payload from storage only when it's ready to process it. The broker never touches the heavy bytes; it just carries the ticket.
Step through one video's trip. Watch the sizes on each token: the queue carries 0.4 KB while the 50 MB goes straight from storage to the worker. At the end, predict what happens to the stored video, then flip between leaving it behind and deleting it.
Plan the payload's lifecycle. A claim check is useless if the coat has been thrown out — and the cloakroom overflows if nobody ever collects coats. Delete the payload once it's been processed, and add a time-based lifecycle rule as a backstop for consumers that crash halfway. With pub/sub fan-out, no single subscriber knows when the others are done, so lean on the time-based rule there instead of letting the fastest subscriber delete it.
You moved to claim check, so messages now carry only a blob name. Six months later the queue is empty, yet storage costs keep climbing. What's the likely cause?
Securing the ticket
A claim ticket is more than a name: whoever holds it can usually fetch the payload. Messages get copied into logs, dead-letter queues and debugging tools, so assume someone other than your consumer will see a ticket one day.
There are two common ways to keep that safe. Either the ticket carries a short-lived, read-only link to exactly one blob (on Azure, a shared access signature that expires in minutes), or the ticket carries only the blob's name and each consumer reads the store with its own identity, so a leaked name is useless without permission. Either way, the store itself stays private.
Don't put a master key in the ticket. A link that never expires, or one that can read or write a whole container, turns every copy of every message into a skeleton key for your data. Scope each link to one blob, read-only, with an expiry just longer than the consumer needs.
When to use it
Reach for Claim Check whenever messages would otherwise carry large or variable-size payloads, especially if you risk hitting broker size limits or you want to keep queue-based load leveling snappy and cheap. It pairs naturally with pub/sub fan-out — many subscribers can share one stored payload via the reference — and with competing consumers pulling work off the queue. The stored payload can even act like a cache others reuse.
Skip it when payloads are already tiny: the extra storage round-trip and cleanup logic aren't worth it for a few hundred bytes. Claim Check earns its keep precisely when the thing you're moving is too big to comfortably mail.
A teammate puts a storage link that never expires, and can write to the whole container, into every claim ticket. What's the risk?