Recording every allowed authorization decision on a busy broker is usually rejected. What drives that cost, and what narrower configurations keep some value?

## Where the cost actually is It is tempting to read "record every allowed decision" as a storage problem. It is two problems, and the first is the one that gets the proposal rejected. **The check is on the serving path.** A broker consults the grant table while it is answering a client. Turning a decision into a durable record adds work — formatting, buffering, and eventually a write to somewhere — inside the latency budget of the operation the client is waiting on. Implementations buffer and batch to keep it off the critical path, which converts the latency cost into a memory cost and a loss window: whatever is buffered when a node dies is the part of the trail you do not have. **The volume follows the request shape, not the data shape.** How often a decision is taken varies by design. Where every fetch or publish is a separate request, the decision is per request, and one audit record per authorized request means a trail with a record count comparable to the operation count of the cluster. Where a subscription is established once and then served, the decision may be taken once per subscription, and complete recording is almost free. The same feature is therefore cheap on one platform and unaffordable on another, which is why blanket advice about it is wrong as often as it is right. **The destination compounds both.** If audit records are written back into a stream on the cluster they describe, they are themselves writes — which are themselves authorized, which produces further decisions to record. That feedback is bounded in practice by excluding the audit stream from recording, but the load is not: you have added traffic to the cluster whose behaviour you were trying to observe. ## The narrower configurations, and what each one gives up | Configuration | Volume | What it proves | What it cannot show | |---|---|---|---| | Refusals only | Very low | Who was turned away, and when a client is probing or misconfigured | Any access by a principal whose grants already permit it | | Named subset of streams or principals | Proportional to the subset | Complete access evidence where it was decided it matters | Anything outside the subset, chosen before the incident | | One record per session | Low | That a principal touched a stream at all, and when | Volume, repetition, and the shape of the access | | Sampling | Tunable | Statistical patterns across principals and streams | Whether one named access happened — the evidential question | The ordering matters. Each row down the table buys volume reduction with a specific piece of evidence, and the decision is about which evidence you are willing to be without when someone asks a year later. 1. **Start from the question.** Decide which streams would trigger an investigation if they were read by the wrong principal. That list is almost always short, and it is the natural subset. 2. **Keep refusals unconditionally.** They are the cheapest row and they carry a different signal from the others — a rising refusal count is a client that was reconfigured, a credential that was replaced badly, or someone trying doors. 3. **Choose the session-level option deliberately, not by default.** It answers "did this principal ever touch this stream" and nothing finer. For a grant review that is often enough; for an investigation into how much data left, it is not. 4. **Treat sampling as measurement, not as evidence.** A sampled trail is useful for seeing which principals dominate access to a stream. It cannot exonerate anyone and it cannot convict anyone. ## The rented case, which is not a configuration at all On a managed tier the operator has already made these choices. You typically get a switch, a destination, and a fixed set of categories. Sometimes allowed decisions are simply not among them — the tier emits connection records and refusals and that is the whole product. Sometimes the granularity is fixed at one level that suits the operator's own cost model rather than your investigation. Neither can be widened by asking nicely in an incident, so the time to find out which you have is before you write a control that depends on it. ## The common mistake The mistake is to switch full recording on in an incident, observe that the cluster copes at that moment, and leave it on. Access traffic is bursty, the trail's cost scales with the busiest hour rather than the average one, and the destination it writes to has its own limits. The safe version is a **time-boxed window**: full recording for a named set of streams, for a stated period, with a decision at the end about which narrower row of the table to settle on.