Beyond reading and writing records, which operations does a broker authorize separately, and why does that separation matter?
answer
- not a file with two bits
- create, delete, alter, describe
- listing names is disclosure too
- retention change destroys without deleting
basics
~20 sBrokers separate far more than reading and writing: creating a stream, deleting it, changing its settings, listing or describing names, recording a read position, and cluster-wide administration are distinct rights. Teams that grant only two end up granting all of them.
solid answer
~50 sA stream is not a file with read and write bits. Most brokers authorize creation, deletion, configuration change, metadata listing and cluster administration as operations in their own right, and where readers store a position in the cluster, recording that position is separate from reading. The separation matters because the failures are asymmetric: a reporting job that should only read can, under one coarse right, delete the stream it reads from, and a listing right that looks harmless exposes every stream name in the estate - which is a map of the business, not a technicality. Platforms differ in how they carve the set, and some fold creation into writing when a write to an unknown name brings the stream into existence, so the honest answer names the categories and then asks which ones this cluster actually distinguishes.
go deeper
Recall that a broker permits more than reading and writing: creating, deleting, changing settings and listing names are each their own right. Note that some are bundled together on some platforms.
Explain each category and what holding it really permits - especially that a retention change destroys data and a listing right discloses the estate. Say which ones your cluster actually distinguishes.
Show the mapping discipline: every workload gets the narrowest operation set it genuinely performs, with creation and deletion kept away from the services and held by whoever operates the estate.
Argue the estate-wide carve-up. A model with three coarse bundles is cheap to administer and guarantees over-granting; one with a dozen verbs is precise and goes unmaintained. Decide which failure you would rather own.
## Why "read and write" is the wrong model The file-permission habit - read, write, maybe execute - is where most candidates start, and it is the reason grant tables collapse into two rights that mean far more than they say. A broker holds named, long-lived, shared resources that clients do not only consume but also **create, reshape, drain and destroy**, and each of those is a separate thing to be permitted or refused. ## The categories brokers actually distinguish Names differ between platforms; the categories are stable: - **Append / publish** - put records into a named stream. - **Consume / read** - retrieve records from it. On a cluster with retention, this right reaches every record still held, which may be far older than the grant. - **Create** - bring a new stream into existence. On platforms where writing to an unknown name creates it, an append right is quietly also a creation right; on others creation is strictly separate. - **Delete** - destroy a stream, or remove records from one. This is the operation whose blast radius is largest and whose grant is most often bundled with writing. - **Alter configuration** - change a stream's settings, including how long its records survive. Someone who can shorten a retention window can destroy data without ever holding a delete right. - **Describe / list** - see that a name exists and read its shape. Frequently treated as harmless. - **Record a read position** - where the cluster stores how far a reader has got, writing that position is its own right, distinct from reading. On designs where acknowledgement removes the record instead, there is no stored position and therefore no such right, which is exactly why this has to be asked per platform. - **Cluster administration** - node-level and cluster-wide operations that no stream grant should ever imply. | Operation | What holding it really permits | Common bundling mistake | |---|---|---| | Append | put records into a name | also creates the name on platforms that create on first write | | Consume | read all retained history, not only new records | granted "for a quick investigation" and never withdrawn | | Create | add names to a shared cluster | folded into append and never noticed | | Delete | destroy a stream or purge records | issued together with append as one "producer" right | | Alter configuration | shorten retention, i.e. destroy data indirectly | treated as an operational nicety rather than a data right | | Describe / list | learn every stream name that exists | considered read-only and therefore harmless | ## Why the separation is not pedantry Three concrete consequences: 1. **Asymmetric damage.** Reading the wrong stream is a confidentiality incident that can be contained. Deleting one, or shortening its retention, destroys data that may be the only copy between two systems. Bundling those rights makes an operational mistake into an unrecoverable one. 2. **Listing is disclosure.** A complete list of stream names describes an organisation's systems, its customers' segmentation, its unreleased projects and its acquisitions. A right that returns names but no records still leaks. 3. **Configuration change is a data operation.** Retention is a setting, so a permission model that thinks of settings as "admin" and records as "data" will hand the retention right to whoever operates the cluster and be surprised when history vanishes. ## What a good answer says about variation The carve-up is not identical everywhere, and saying so is part of the answer rather than a hedge. Some platforms model a small set of coarse operations and expect fine control to come from the resources rather than the verbs; others enumerate a dozen. Some expose cluster administration as a single right; others break it apart. A managed tier may collapse the whole set into two or three named bundles, which is precisely when a team ends up giving a read-only consumer the right to delete. The operational move is the same regardless: enumerate what your cluster distinguishes, then map each workload to the *narrowest* set of operations it actually performs - which is usually append-only or consume-only, with creation and deletion held by whoever operates the estate rather than by the services running on it.
- Why is the right to change a stream's settings a data right rather than an administrative one?Because retention is a setting. Shortening the window a stream's records survive removes data as surely as deleting them, without ever invoking a delete operation, and it does so silently - the stream still exists and still accepts writes. Any permission model that files settings under administration and records under data will hand that right to the wrong people. Treat configuration change on a stream as equivalent in power to deletion.
- A team argues a listing right is harmless because it returns no records. What is your answer?The names are the leak. A full list of streams across an estate reveals which systems exist, which customers or regions are modelled separately, and which projects are being built before they are announced. It also gives anyone who later obtains a read right a precise target list. Grant listing at the narrowest scope that lets a client find what it already knows it needs.
saying these in an interview costs you the question
- Says a broker only distinguishes producing from consuming
- Thinks deleting a stream requires nothing beyond the right to write to it
- Treats the right to list stream names as harmless because no records are returned
- Assumes changing a stream's settings cannot destroy data
- Believes cluster-wide administration is covered by grants over streams