Should grants over streams be evaluated by the broker itself or by the platform the cluster runs on, and what does each cost?
answer
- same question, different decision point
- granularity against coherence
- what is reachable at connect time
- coarse outside, fine inside
basics
~20 sThe broker's own evaluation expresses stream operations precisely and survives the platform being unreachable, but is a second permission system to run. Platform evaluation unifies the estate and loses granularity. Most large estates end up with both.
solid answer
~50 sTwo decision points are available. The broker can hold its own grant table and evaluate it, or it can delegate and ask the surrounding platform whether this principal may perform this operation on this name. Broker-side evaluation wins on **granularity** - it knows what appending, creating and altering a stream are, whereas a platform model often knows only coarse actions over a whole cluster - and on **independence**, because the decision does not depend on another system being reachable at connect time. Platform-side evaluation wins on **coherence**: one place to grant, one vocabulary across every resource an organisation runs, and no second review to remember. The costs are symmetric and worth naming out loud: a broker table is invisible to the estate's tooling and moves with nothing; platform rules are coarser, are usually unavailable on another vendor's cluster, and put a dependency on the platform in the connect path.
go deeper
Recall that the same four-part rule can be evaluated by the broker or by the platform around it, and that the broker's own model usually describes stream operations more precisely.
Explain the trade in terms of granularity and dependency: the platform unifies grants across the estate but often loses the distinction between appending, creating and deleting on one stream.
Show what you would check before committing: whether per-stream operations are expressible, how withdrawal propagates if decisions are cached, and what happens when the deciding system is unreachable.
Own the estate-level call. Name the axes, say which ones this organisation is paying for, and commit - usually coarse access outside and fine operations inside, with the two-system cost stated rather than hidden.
## What is actually being chosen Both arrangements answer the same four-part question - which principal, which operation, which named resource, permit or refuse. What differs is **which system holds the rule and performs the evaluation**, and that choice propagates into who may change a grant, how precisely it can be written, what it takes to audit, and what happens when something is down. ## The two arrangements | Axis | Broker evaluates | Surrounding platform evaluates | |---|---|---| | Operation granularity | Knows appending, consuming, creating, altering, describing as distinct verbs | Often a handful of coarse actions, sometimes only "use this cluster" | | Resource granularity | Individual streams, fragments, namespaces | Usually the cluster as a resource; per-stream rules may not be expressible | | Who may change a rule | Whoever administers the cluster | Whoever administers platform access, usually a different team | | Availability of the decision | Local to the cluster; no external dependency at connect time | Depends on the platform's decision path, which is typically cached but not free | | Fit with the rest of the estate | A separate system nobody else's tooling reads | The same vocabulary as everything else the organisation runs | | Portability | Moves with the cluster; concepts transfer between brokers | Tied to that platform; a cluster elsewhere cannot use them | ## Where each one actually hurts - **Broker-side is a second permission system.** It has its own review, its own change path and its own drift, and none of the estate's existing tooling can see it. A team that has invested heavily in one way of granting access now has two, and the second one is the one people forget. - **Platform-side loses the verbs.** If the platform model cannot express "append but not delete" on one stream, every principal gets the coarsest right that lets it do its job, and all the discipline about separating operations collapses into a single bundled right. This is the most common real cost and the least often anticipated. - **Platform-side adds a dependency to the connect path.** Deciding permission elsewhere means something must be reachable, or a cached answer must be trusted. Caching is what makes it workable and also what makes a withdrawal take effect later than the person who withdrew it expects. - **Broker-side rules do not travel.** They also do not stop travelling: a grant table copied with a cluster during a migration arrives intact, which is helpful and occasionally means an old estate's rules are quietly running on a new one. ## The practical positions 1. **Coarse outside, fine inside.** The platform decides who may reach the cluster at all; the broker decides what each principal may do to which stream. This is the arrangement most mature estates converge on, and its cost is honest - two systems, deliberately, with a documented split. 2. **Platform only.** Justified where the operation set genuinely is coarse (one team, few streams, no separation between producing and administering) and where the value of one grant vocabulary across the whole organisation outweighs the lost verbs. 3. **Broker only.** Justified where the cluster is not on a platform with a usable access model at all, or where it must keep deciding correctly when everything around it is degraded. ## What a rented cluster does to the choice A managed tier may make it for you. Some expose only the platform's model, which sets the granularity ceiling regardless of what the underlying broker can express; some expose the broker's own table as well; some offer a fixed set of named bundles that is neither. Establish which of the three you have *before* designing the estate's separation of duties around it, because discovering that per-stream rules are not expressible after teams have been promised them is an expensive reversal. ## How to answer this in an interview Do not pick a side in the abstract. Name the axes - granularity, who changes a rule, availability of the decision, portability, coherence with the estate - state which of them the organisation in question is actually paying for, and then commit. The strongest version of this answer usually ends at the split arrangement, with the reason given as granularity: the platform has no reason to know what appending to a stream means, and the broker has no reason to know who a contractor is.
- What is the most common hidden cost of delegating the decision to the platform?Lost verbs. Platform access models tend to express coarse actions over a whole cluster, not appending as distinct from deleting on one stream. Every principal then receives the coarsest right that lets it work, and the separation between reading, creating and destroying quietly disappears. It is easy to miss during evaluation because the first workloads modelled usually need broad rights anyway.
- If the platform's decision path is cached, what changes about withdrawing a grant?It stops being immediate. A withdrawal takes effect when the cache expires or is invalidated, so a principal can keep acting for a window after someone believes the access is gone. That matters most during an incident, when the withdrawal is the containment step. Know the window, and know whether the broker also holds long-lived connections that are not re-checked.
saying these in an interview costs you the question
- Assumes a platform access model can express every broker operation
- Argues one decision point is correct without naming what the estate is paying for
- Ignores what happens when the external decision path is slow or unreachable
- Expects rules written for one platform to travel with the data to another cluster
- Thinks a rented cluster always leaves the choice open to the tenant