Maximum record size is set separately at the writer, the accepting node, the copy hop and the reader — which one decides?

## The four gates A record does not clear one ceiling; it clears a chain of them. Each hop on its path can enforce a maximum on a single record, and each is configured somewhere else: 1. **The writer's own ceiling.** Client libraries commonly hold a maximum request or record size and refuse the call locally, before anything reaches the network. It lives in application configuration, not on the cluster. 2. **The accepting node's ceiling.** The node the writer is connected to checks the record when it arrives and refuses it if it is too large. This is the one people mean when they say "the broker limit". 3. **The copy hop's ceiling.** On platforms that make a record durable by transferring it from the node that accepted it to nodes holding other copies, that transfer is itself a request with its own maximum. Where storage is shared between nodes, or where a write is made durable by several nodes accepting it directly rather than by a follow-up transfer, there may be no separate gate here at all. 4. **The reader's ceiling.** A reader will accept a response, and a record within it, only up to a size of its own — again in client configuration, owned by whichever team runs the consuming application. ## The smallest gate binds The useful mental model is the lowest bridge on a route: raising three of them changes nothing while the fourth is still low. A record passes only if it is under **every** ceiling it meets, so the effective ceiling for the path is the minimum of the four. Everything else about the failure follows from *which* of the four is the minimum. | Smallest gate | Who sees the failure | What it looks like | When you find out | |---|---|---|---| | The writer's | the writing application | the send call fails locally, no round trip | immediately | | The accepting node's | the writing application | the write is refused with a size reason | immediately | | The copy hop's | the operator | the record is accepted, then the set of copies stops keeping up | minutes later, as a durability symptom | | The reader's | one consuming application | the record is stored and readable by others, but that reader will not take it | possibly days later | The first two are benign in the sense that they fail loudly at the moment of the write, in front of the person who produced the record. The last two are the reason this subject is asked at all: the record was **accepted**, so the writing side thinks it succeeded, and the consequence appears somewhere else, later, to somebody else. ## Why the gates drift apart - They have **different defaults**, chosen independently by the platform for the writer, the node and the reader. - They are **changed in different places**: the node's is an operator change on the cluster, the other three are application configuration that requires a release. - They are **owned by different teams**. The cluster team can raise the node's ceiling in an afternoon and has no authority over twenty consuming applications. - A **new consuming application** arrives with stock configuration long after the ceiling was agreed, and reintroduces a low gate nobody remembers. ## Raising the chain safely 1. Enumerate the hops a record actually takes on your platform, including whether a copy hop exists as a distinct gate. 2. Read the **effective** value at each — the value in force, not the one in a template — and take the minimum. 3. Compare that minimum with the tail of your real record-size distribution, not its average. 4. Raise in reading order: **readers first**, then the storage path, and the writer's ceiling last. A reader that can take more than exists is harmless; a writer allowed to produce more than a reader can take is the failure in the table above. 5. Record the agreed ceiling somewhere the next consuming application will see it, because the gate you cannot see is the one that will bind. ## Where platforms differ - **Whether a copy hop exists.** Some designs replicate by transferring accepted records between nodes; others share storage, and others make a write durable by several nodes accepting it directly. - **What the reader's ceiling is expressed against.** On some it is a maximum per record; on others a maximum per response, which interacts with how many records come back at a time. - **Which bytes count.** Payload alone on some platforms, payload plus key and attached metadata on others — so two clusters with the same configured number do not accept the same records. - **Whether the node re-checks after any transformation.** If a node has to decode and re-encode what it received, the size it checks is not necessarily the size that arrived.