A value has a cluster-wide default and a per-stream override on one stream — which value does that stream use, and which do the rest?
answer
- one setting, more than one scope
- most specific scope wins
- default covers only un-overridden objects
- effective value is a per-object answer
basics
~20 sThe override wins for that one stream; every stream or queue without an override follows the cluster-wide default. The effective value is therefore a per-object answer, and editing the default leaves overridden objects exactly where they were.
solid answer
~50 sBrokers in this class resolve a setting from the most specific scope that carries a value. A **cluster-wide default** covers every stream or queue that says nothing; a **per-stream or per-queue override** attached to one object wins for that object alone. So the honest answer to "what is our value for this setting" is per object, not one number: you read the default to learn what the un-overridden objects do, and you enumerate the overrides to learn the rest. The practical consequence is that raising or lowering the default moves only the objects with no override — an override set once, years ago, quietly survives every later edit of the default and keeps behaving as whoever set it intended. Platforms differ in how many scopes exist between those two, and some settings are offered at only one of them.
go deeper
Remember the direction: the value set on one stream or queue beats the cluster-wide default for that object, and the default covers everything else. Say that plainly rather than hedging.
Explain resolution as most-specific-wins, and note that some platforms add a scope between the two and that some settings are offered at only one scope.
Show that you would enumerate overrides before editing a default, and describe the stale override that survives every later edit as the failure you actually plan for.
The interesting call is governance: who may create an override, whether an exception carries an owner and an expiry, and whether the default still describes the estate at all.
## Two places the same value can live Every broker and streaming platform in this class has to answer the same question at runtime: *for this particular stream or queue, what is the value of this setting?* Two scopes are near-universal. - A **cluster-wide default** is the value in force across the cluster for every object that does not say otherwise. It is what an operator edits when they mean "from now on, this is how we behave". - A **per-stream or per-queue override** is the same setting attached to one object. It wins for that object and has no effect on any other. The resolution rule is *most specific scope that has a value wins*. A broker node handling a request for a given stream looks for that stream's own value; if the stream carries none, it falls back to the cluster-wide default; if that is unset too, it uses whatever the software ships with. ## What that means for "what is the value" It means the question has no single answer at cluster level. There is a default, and there is a set of exceptions, and the effective value is only defined per object. Reading the default and reporting it as the cluster's behaviour is the most common way an operator misreports their own system — it is accurate only for the objects nobody has ever touched. | Scope | What it covers | When it is consulted | The way it misleads | |---|---|---|---| | Cluster-wide default | Every stream or queue with no value of its own | Only after the object's own value is found missing | Read alone, it describes objects that may be a minority | | Per-stream or per-queue override | Exactly one object | First | Invisible unless you enumerate objects, not settings | ## The override that outlives every edit of the default This is the part that turns a harmless mechanism into an operational surprise. Suppose a team sets an override on one busy stream during an incident, because that stream needed to behave differently from everything else for a week. The incident ends; the override stays. Two years later somebody edits the cluster-wide default — a perfectly ordinary change, reviewed, applied, verified. Every object moves except the one that needed the change most, because an override is not a copy of the default that tracks it: it is an independent value that was frozen at the moment it was written. The same shape appears in reverse. An organisation that sets an override on *every* object — often because a provisioning step does so automatically — has a cluster-wide default that is pure decoration. Editing it changes nothing at all, and the operator who edited it will believe otherwise until something is measured. ## Where platforms genuinely differ Do not assume the two-scope picture is the whole model everywhere: - Some platforms insert a further scope between the two — a per-tenant or per-namespace value that applies to a whole group of objects and is itself overridable per object. Resolution still runs most-specific-first, but there are three places to look, not two. - Some settings exist at only one scope. A value describing how a single machine runs — where it listens, how its storage area is arranged — is usually cluster-or-node-level only and cannot be attached to a stream at all. A value describing how one object behaves is often object-level only. - On a rented cluster the split can be imposed on you: the provider may own the cluster-wide default entirely and expose only the per-object scope, so the same mechanism is present but half of it is not yours to edit. - The unit differs with the shape of the platform. Where a stream is split into parts, an override is usually attached to the whole stream; where consumers compete on a shared queue, it is attached to the queue; some designs attach it to the subscription instead, so two readers of the same data resolve different values. ## What an operator does about it 1. Before editing a cluster-wide default, **enumerate the objects that override it**. The change's real blast radius is the complement of that list, and it is frequently much smaller than expected. 2. Record, next to each override, **why it exists and who owns it**. An override with no recorded reason is the one that will contradict a future change. 3. After applying the change, **verify effective values on the objects you care about**, not the default you just wrote. The write succeeding says nothing about what any given stream now does. 4. Treat "we set that cluster-wide" in a design discussion as a claim to check rather than a fact, because the speaker is describing the default and the system is running the overrides.
- If an override and a cluster-wide default disagree, how would you find out which objects are actually affected by a proposed edit to the default?List the objects that carry their own value for that setting; the edit reaches everything else. Do it by asking the cluster for each object's effective value rather than by reading a settings file, because the file describes the default and the exceptions live on the objects. The list is also the review artefact: anything on it needs an owner who can say whether the exception is still wanted.
- Is an override removed when the cluster-wide default is edited?No. The two are independent values, and editing one does not clear the other. Removing an override is a separate action on that object, after which it falls back to whatever the default then holds. That fallback is evaluated at read time, so an object whose override is cleared picks up the current default rather than the one in force when the override was set.
A chain of shops publishes one price list, and one shop has a hand-written sticker on a shelf. Head office reprints the list; every shelf moves except the stickered one, because a sticker is not a copy of the list that follows it — it is a value someone froze.
saying these in an interview costs you the question
- Thinks editing the cluster-wide default changes every stream's behaviour
- Assumes the broader scope wins over a per-object override
- Reads the cluster-wide default and reports it as the effective value
- Believes an override is cleared when the default is edited
- Assumes every setting is available at both scopes on every platform