A broker cluster gives each team its own named space for its streams — which properties does that space scope, and which does it not?
answer
- administrative line, nothing physical
- three scoped things, one shared cluster
- names, grants, quota attachment
- same disks, same nodes, same outage
basics
~20 sA named space scopes three things: the names streams may take, the grants written against them, and the point a quota attaches to. Nothing physical is scoped — disks, memory, network and node failure stay shared across every space on the cluster.
solid answer
~50 sA named space — or, where the platform provides none, a name prefix with grants written against it — is an administrative boundary, not a physical one. It scopes **names**, so two teams can each own a stream called `orders` without colliding; **grants**, so one rule can be written for the whole space instead of one per stream; and **quota attachment**, where the platform lets a ceiling hang off the space at all. It scopes nothing underneath: both teams' records land on the same storage, compete for the same page cache, network and request threads, and go quiet together when a node is lost or the cluster is upgraded. When someone says a space isolates two workloads, the useful reply is *isolates from what* — from name collisions and casual access, yes; from load and from failure, no.
go deeper
Remember the short list: a named space scopes stream names, the grants written against them, and where a quota attaches. Nothing underneath the cluster is divided by it.
Be able to explain why the boundary is administrative. The space is metadata the platform matches names and rules against, while records still go to the same storage and requests to the same handling capacity.
Show that you have felt it: one team saturating the cluster slows every space, and a bad upgrade takes them all down together. Name which concerns the space genuinely removes and which must be handled some other way.
Treat the isolation claim as a contract other teams design against. Before anyone plans a latency-sensitive workload on the strength of it, narrow the claim to names, grants and quota attachment in writing.
## The boundary in one line A **cluster** is a set of nodes serving named, durable **streams** behind one endpoint set. The moment two teams write to the same cluster, something has to decide which names belong to whom, who may touch them, and whose traffic counts against whose budget. **A named space** is that decision made first-class: a container the platform itself understands, into which streams are created and against which rules can be written. Platforms differ sharply here. Some provide such a container; others provide nothing but naming freedom, and there the same job is done by **a name prefix** — a convention that all of a team's streams begin with an agreed string, backed by **grants** written against that string. Either way, the boundary is made of metadata and rules. It is never made of hardware, and almost every misunderstanding about it starts there. ## The three things it scopes 1. **Names.** Inside a space, a stream name only has to be unique within that space. Two teams can each create `orders` and end up with two distinct streams rather than an argument. Without a space, uniqueness is cluster-wide and the prefix convention exists precisely to keep teams out of each other's name range. 2. **Grants.** A space gives access rules something to be written against that is larger than one stream. One rule covering the space applies to the streams created in it later, which is the difference between a rule set that grows with the estate and one that has to be edited every time a stream is born. 3. **Quota attachment.** Where the platform supports it, the space is something a ceiling can hang off, so a budget can be stated per team rather than per client. Platforms vary on whether this is possible at all — several attach a ceiling only to a client identity or only cluster-wide. A fourth benefit follows from those three rather than being scoped by the space: it gives the estate a unit. Ownership records, reviews and inventory can be kept per space instead of per stream, which is how a governance process stays smaller than the number of streams. ## What it does not scope - **Storage.** Records land on whatever the cluster stores on — local disks on the nodes, or remote object storage in designs that use it. The space names them; it does not place them. - **Memory and cache.** Reads served from a cache are served from one cache, shared by every space. - **Network.** One set of interfaces, one endpoint set, one contended pipe. - **CPU and request handling.** Requests from every space queue for the same handling capacity. - **The failure domain.** A lost node, a rolling restart, a version upgrade or trouble in the metadata and coordination layer is felt by every space at once. - **Grants written above it.** A principal holding a cluster-wide or pattern-wide rule reaches inside every space; the boundary is exactly as strong as the grant set, never stronger. | Property | Scoped by a named space? | What that means in practice | |---|---|---| | Stream names | Yes | The same name in two spaces is two streams | | Access grants | Yes, where rules are written against the space | New streams inherit the rule instead of needing one | | Quota attachment | Only where the platform offers it | Otherwise a ceiling attaches elsewhere entirely | | Disks and cache | No | One team's volume of data pressures everyone | | Network and request capacity | No | One team's traffic is felt in every space | | Node loss and upgrades | No | Every space shares one availability story | ## Where platforms differ - Some give a **first-class container**; others give **only a prefix convention**, where membership is a string comparison rather than a property the platform holds. - Some let a grant be written against a prefix or pattern; others only against an exact stream name, which turns the boundary into an administrative process rather than a rule. - Quota attachment lands in different places: the space, a name pattern, a client identity, or nothing finer than the cluster. - Some allow **child spaces** nested under a parent; others are strictly flat. ## Answering it in an interview Lead with the short formula — *names, grants, quota attachment, and nothing physical* — then give one consequence that proves you have seen it: two teams in two spaces still share every disk and every failure of the same nodes. The interviewer is checking whether you know that the boundary is administrative leverage rather than separation, because a candidate who thinks otherwise will one day put a latency-sensitive workload next to a batch one and call it isolated.
- Your platform offers no first-class named space. What takes its place?A name prefix plus the grants written against it. Every one of a team's streams begins with an agreed string, and access rules — and a ceiling, if the platform allows it — are expressed against that string. The convention itself enforces nothing; only the grants do, so a stream created outside the prefix is outside the boundary while working perfectly well for whoever created it.
- Does a named space stop one team from reading another team's stream?Only through the grants written against it. The space makes the rule cheap to express — one rule per space rather than one per stream — but a principal holding a cluster-wide or pattern-wide grant reaches inside every space. The space is where a rule is attached, not a rule in itself.
- If a space scopes nothing physical, what is it actually worth?Three things that are expensive without it: names that cannot collide across teams, an access rule that does not have to be rewritten for every new stream, and one place to attach a budget and hang ownership records. That is administrative leverage, which is most of what day-to-day estate work consists of.
Suites in one office building. Each has its own door, nameplate and keys, so nobody else's post lands on your desk and nobody wanders in. All of them still share one lift, one power feed and one roof — and when the roof leaks, the nameplate does not help.
saying these in an interview costs you the question
- Thinks a separate named space means separate disks or separate nodes
- Assumes creating a space by itself limits how much cluster capacity a team takes
- Believes a cluster-wide upgrade or a lost node affects only one space
- Treats the space boundary as access control with no grants written behind it
- Says two teams in two spaces cannot affect each other's latency