You're reviewing a proposed architecture where every message on an internal event bus, regardless of size, gets routed through claim check by default: producers always write to object storage first and always publish just a reference, even for a 500-byte status update. What's wrong with this default, and when does claim check genuinely not pay for itself?

## Why a blanket default is an overreach Applying claim check as a blanket default rather than a targeted response to an actual size constraint is a common architectural overreach, and it's worth being precise about why, because the failure isn't that claim check is a bad pattern -- it demonstrably solves a real problem -- but that patterns solving a specific constraint stop paying for themselves the moment that constraint isn't actually present. A 500-byte status update message never came close to threatening a broker's 256 KB limit, has no throughput or replication cost concern that externalizing it would address, and yet under a blanket policy it now: - incurs a mandatory extra network round trip to object storage before a consumer can do anything with it; - depends on a second system's availability for every single message rather than only the ones that need it; - inherits the write-then-publish ordering discipline and cleanup lifecycle obligations that claim check requires. All for a payload that would have been perfectly fine riding inline on the bus. Multiply that overhead across every message type in a system and the aggregate cost -- in latency, in storage API call volume and its associated cost, in operational surface area -- is pure loss with no offsetting benefit, because the benefit claim check offers is specifically proportional to how much it's saving the broker from carrying large payloads, and there's nothing to save here. ## Where the line actually sits The more interesting question is where the line actually sits, because 'use claim check when payloads are large' is true but underspecified. | Payload size | The move that fits | | --- | --- | | **At the small end** -- payloads comfortably within a broker's limit | Should simply go inline; there's no ambiguity there. | | **In the middle band** -- payloads that occasionally or moderately exceed a limit, say a JSON payload that's usually 50 KB but spikes to 400 KB for a small fraction of messages against a 256 KB cap | The better first move is often compression (structured JSON and text typically compress well, frequently by 70-90%) or picking a broker configuration with a higher ceiling, both of which solve the problem without introducing a second system or the consistency and lifecycle concerns claim check brings. | | **Routinely megabytes to gigabytes** -- media files, large documents, bulk data exports | Claim check earns its complexity specifically here, where no reasonable amount of compression or limit-raising would bring them into a broker's comfortable operating range, and where the cost of running a second system is clearly smaller than the cost of forcing that data through the broker itself. | ## In the large-payload regime: one wrong tool, one complexity to budget for Even within that large-payload regime, there are situations where claim check specifically is still the wrong tool. - **A genuinely latency-critical synchronous path** -- a request that a human or another service is blocking on and waiting for a response within a tight budget. On such a path the extra round trip to storage, even if it's only tens of milliseconds, may not fit the latency budget at all, and the better design is often to skip the broker entirely for that path and have the caller talk to storage directly via a link returned synchronously from an API call, rather than routing a large payload through an asynchronous claim-check pipeline that was never meant to serve tight-latency use cases in the first place. - **Heavy fan-out scenarios,** where a large payload needs to be read by many independent consumers. In those, claim check still generally makes sense for the broker-load reasons already covered, but it shifts real complexity onto payload lifecycle management -- deciding who's responsible for cleanup, how long objects need to live to cover the slowest consumer, whether completion tracking is needed -- and a team adopting it needs to budget for that complexity explicitly rather than treating claim check as a drop-in size fix that magically also solves fan-out coordination for free. ## The principled default is conditional The principled default, then, is conditional rather than universal: route messages inline unless a payload's actual or reasonably-anticipated size would violate the broker's constraints, and make that decision based on measured size rather than by message category or team convention, ideally automated in a shared producer library that checks payload size at publish time and only writes to storage and constructs a claim check when the payload exceeds a configured threshold, falling back to inline delivery otherwise. This keeps the common case -- the vast majority of messages in most systems, which are small structured events -- cheap and simple, while still handling the genuine outliers correctly, and it avoids exactly the failure mode in the scenario, where an architectural decision meant to solve a specific, occasional problem got applied uniformly and turned into a tax paid by every message regardless of whether it needed the fix at all. ## Getting it right, concretely A concrete real-world instance of getting this right: an e-commerce platform's order-events bus sends small JSON order-state-change events inline for the overwhelming majority of traffic, but a separate returns-processing flow that occasionally attaches customer-uploaded photos of damaged items routes only those specific messages through claim check, keyed off the presence of an attachment rather than being a blanket policy for the whole events bus -- the vast majority of that system's message volume never touches the second system at all.