Two teams collapse round trips to a shared volatile tier in different ways — what must a platform-wide guideline fix rather than leave to each team?

## Why this cannot be left to each team Two teams looking at the same tier will reach different answers, and both will be locally defensible. One sends runs of ten thousand operations because it measured them as fast on an idle tier. Another uses one operation naming many keys because its client library made that easy. Neither can see the other's memory in flight, neither knows the aggregate trip count on the tier, and neither is wrong from where it stands. The costs they create are **shared**; the decisions they made were **local**. That gap is exactly what a platform-level contract exists to close. ## What the guideline must fix 1. **A bound on unread reply bytes per connection, and the concurrency multiplier.** A run's cost is held in the reply buffer at each end, and the figure that matters to the tier is the per-run bound times the number of connections doing it at once. Publish both numbers; a team cannot derive the second one. 2. **A trip budget per request path.** "This path may cross the network to the tier at most N times" converts a vague instruction into an assertion that can be tested. It also exposes the better answer that tuning never finds: removing a trip entirely. 3. **The property statement.** Collapsing trips buys latency and nothing else — no atomicity, no isolation, no all-or-nothing outcome. Put it in writing, because the failure mode it prevents is a design document that cites a batch as the reason two updates cannot be seen apart. 4. **The error contract.** Every operation in a run has its own outcome and all of them are inspected; a collapsed write is safe to re-issue where the operation allows it, because a connection-level failure loses outcomes while leaving effects applied. 5. **The partitioned-tier rule.** Whether the client libraries in use know the key-to-node assignment, and therefore whether a run is split per node and whether an operation naming keys on several nodes is refused or served by something in front. This decides which form each team can even use. ## What the guideline must not assume - **That every store offers an operation taking many keys.** Several stores in this class answer only single-key reads and writes, and some offer a multi-key read but no multi-key write. Guidance that rests on the many-key form stops being true the moment the estate gains a second store. - **That a many-key read is a snapshot.** A store that executes one operation at a time gives you that; a store that serves requests from a thread pool may take the keys one at a time under per-entry locking. - **That one connection's buffered operations run consecutively.** Some implementations do, some do not, and a design that needs it has picked a product without saying so. - **That the execution model is known.** Whether one long run delays other callers, and how much, differs between the two models. - **That a default from one client library is a property of the tier.** Pool sizes and run sizes shipped as defaults are the library author's guess, not a fact about the store. | Fix centrally | Leave to the team | |---|---| | Unread reply bytes allowed per connection | Which call sites are worth collapsing | | Expected concurrency for that bound | The operation count derived from the byte bound | | Trip budget per request path | How the path is restructured to meet it | | The latency-only property statement | The data model that makes writes re-issuable | | Which store capabilities may be assumed | Which allowed form each call site uses | ## The conversation this is really about A contract like this is cheap to write and unpopular to enforce, so tie each line to the failure it prevents: the memory bound to a tier whose connections were dropped mid-run, the property statement to a correctness bug shipped on the belief that a batch was applied together, the capability list to a migration that discovered halfway through that the new store had no many-key write. And keep the most valuable instruction at the top, because it is the one that tuning never reaches: **the cheapest trip is the one the request does not make.** A path that collapses forty trips into one is better than forty; a path that needed none of them because the value travelled with the request is better still.