Why does a prefix or wildcard grant written in a hurry end up covering streams nobody had created when it was written?
answer
- the rule did not change
- names are resolved at request time
- future names, and retained history
- a fragment is only as tight as its owner
basics
~20 sBecause a grant whose resource is a name fragment is matched at request time against whatever names exist then, not against the names that existed when it was written. Every stream created later under that fragment is covered the moment it appears.
solid answer
~40 sA grant's resource can be an exact name, a name fragment, or a match-all. Only the first is fixed. The other two are re-evaluated on every request against the cluster's current names, so a fragment issued to save a ticket in one quarter silently covers every stream created under that fragment afterwards - including ones belonging to a team that did not exist yet. On a broker this widens in a second direction too: a read right reaches all retained history, so granting it over a fragment hands over records written long before the grant. Nothing announces either effect. The grant table looks exactly as it did the day it was written, which is why fragment grants are the most common way a broker's permissions grow without anyone making a decision.
go deeper
Recall that a fragment resource is matched against current names, so streams created later fall under an old grant automatically. Nothing about the rule changes when that happens.
Explain both directions of widening: forward onto future names, backward across retained history the moment a read right is issued. Say why the write side is not harmless either.
Show the judgment: fragments are fine where one accountable owner controls which names exist under them, and are effectively match-all where anyone can create such a name.
Treat the resource vocabulary as an estate decision. If the platform only offers exact names and match-all, the widening is structural, and the control has to move to who may create names at all.
## The mechanism A grant names a resource. That resource can be written three ways, and the difference between them is entirely about **when** the name is resolved: 1. **An exact name.** Matched against one stream. The set it covers is fixed at the moment the rule is written and can only change if someone edits the rule. 2. **A name fragment.** Matched against every current name that begins with the fragment. The set is computed *at request time*. 3. **A match-all resource.** Matched against every name on the cluster or in the namespace, also at request time. That is the whole mechanism, and it is why the widening is invisible: nothing about the grant changes. The rule is identical in year three to the rule in year one; what changed is the set of names it is being matched against. A new stream created on Tuesday is covered on Tuesday, with no grant written, no approval, and no event that looks like a permission change. ## Why a broker widens in two directions On a web service, a widened rule exposes future requests. On a broker it also exposes the past, because a stream keeps its records: - **Forward** - every stream created under the fragment from now on is readable or writable by the holder. - **Backward** - the day a read right is granted over a name, the holder can reach everything the cluster still retains under it, which may be weeks or months of records written under a completely different set of expectations. A third-party analytics workload given a fragment read right "for the current project" therefore acquires the project's history and every future project filed under the same fragment. ## The write side is the one people forget A fragment **write** grant is usually reasoned about as harmless because writing is additive. It is not: - The holder can publish into a stream another team creates later, and consumers of that stream have no way to tell the records came from an unexpected writer. - Where writing to an unknown name creates the stream, a fragment write grant is a licence to create names anywhere under that fragment. - If the fragment overlaps the name of a stream a regulator or an auditor cares about, a write from the wrong system is an integrity problem with no clean rollback: appended records cannot simply be unappended. ## What to do with it Fragment grants are not a defect in themselves - they exist because writing one grant per stream does not scale, and a system with thousands of streams cannot be run on exact names alone. The discipline is about **who controls the name space under the fragment**: - Use an exact name where the set is small and stable - most service-to-service pairs are exactly that. - Use a fragment only where a single owner decides which names may be created under it. A fragment grant is worth precisely as much as that ownership; if anyone in the organisation can create a name under the same fragment, the grant is effectively a match-all with extra steps. - Keep the match-all resource for the operational identities that genuinely need the whole cluster, and treat every one of them as a standing risk rather than a rule you have finished with. - Write down, at the moment the fragment grant is issued, the reason it is a fragment rather than an exact name. That sentence is what a later reader needs in order to judge it; without it, every fragment grant looks equally load-bearing and none of them can be narrowed with confidence. ## Variation worth naming Platforms differ in what they even offer here. Some support exact names, fragments and match-all; some support only exact names and match-all, which pushes every team straight to match-all; some express the resource through a namespace instead, so the fragment is implicit in where the stream lives. On a managed tier the resource vocabulary may be fixed and coarse, with the same consequence - if the only rules you can write are broad ones, the widening is structural rather than accidental, and the mitigation has to move to who may create names at all.
- Is a fragment write grant less dangerous than a fragment read grant?It is dangerous differently, not less. A read grant exposes retained history and every future stream under the fragment. A write grant lets the holder publish into streams other teams create later, whose consumers cannot tell the records came from an unexpected source, and on platforms that create a stream on first write it is also a licence to add names. Appended records cannot be un-appended, so the write side has no clean rollback.
- What makes a fragment grant defensible rather than accidental?A single owner deciding which names may exist under that fragment. If any team can create a name beginning with the same fragment, the grant is a match-all with extra steps, because a new name is covered the moment it appears. Where that ownership is real, the fragment is doing exactly the job it should: covering a set that one accountable party controls.
A fragment grant is a key cut to a floor rather than to a door. Every office built on that floor afterwards opens to the same key, the key is never re-cut, and the person holding it never has to ask again - so nobody notices that what they can open grew while the key stayed the same.
saying these in an interview costs you the question
- Thinks a grant only covers the streams that existed when it was written
- Calls a fragment grant safe because the right team owns those names today
- Assumes a new stream is unreachable until someone writes a grant for it
- Believes a read grant only exposes records written after it was issued
- Treats a match-all grant as temporary because it was issued during an incident