Claim Check

Overview

Like a coat check ticket, the message carries a claim token while the heavy item sits in storage.

The order of operations matters: upload first, publish second, so a message never points at a missing object.

A related choice is how consumers authenticate to storage. Pre-signed URLs with short expiry let the message carry a self-contained link, but they can expire before a delayed consumer reads them. References plus consumer IAM roles avoid this, at the cost of managing permissions for every reader.

How it works

The producer uploads the blob, then publishes the reference. Consumers dereference lazily, verifying the checksum.

key = s3.put("payloads/" + uuid, body)
broker.publish("reports", {
  "claim": key, "bytes": len(body),
  "sha256": digest, "type": "report.ready"
})

Some client libraries implement the pattern transparently, offloading bodies above a threshold, for example a quarter of a megabyte. That is convenient, but you still own cleanup and must understand what happens on partial failure. Encrypt stored payloads, since object storage often outlives the broker and holds sensitive data, and tag objects with the message id for traceability.

Pitfalls

• Publishing before the upload completes, so consumers hit missing objects.
• Short TTL on payloads while the queue backlog is longer.
• Mutable objects, which make replays return different data than the original.
• Giving consumers broad storage permissions instead of scoped, expiring access.

Key takeaways

• Upload first, publish the reference second.
• Make payloads immutable and checksummed.
• Align payload TTL with worst-case message retention.
• Scope access to the reference holder.