Why is renaming a live stream a migration rather than an edit, and what is written against the old name?

## The name is the identity The instinct that renaming is cheap comes from files and variables, where a name is a label attached to something that exists independently of it. A stream is not like that. On most platforms in this class the name is the handle the stored object is registered under: there is no rename operation to call, and where something rename-shaped exists it is an alias or a routing rule laid over the old name rather than a change to it. So the honest description of a rename is: create a second stream, move the writers and the readers onto it, and retire the first. The mechanics of that move — running both, deciding when readers have crossed, and the delete at the end — are the retirement procedure and a subject of their own. What matters here is *why* a name change drags that procedure behind it at all. ## The inventory bound to the old string | What points at the name | Who has to re-issue it | What a miss looks like | |---|---|---| | **grants**, often matched as a prefix | whoever owns access rules | writes refused on the new name, or worse, the new name falls under a prefix somebody else's grant already covers | | **quotas** attached to the name or its prefix | the platform team | the new stream runs uncapped, or inherits a ceiling meant for something else | | **retention and copy-count settings** | the stream's owner | the replacement quietly gets the creation-time defaults instead of the settings the old one had | | **mirroring and routing rules** selecting by name | whoever runs the second cluster | the stream stops being copied, and nobody notices until it is needed | | **dashboards, alert conditions, saved queries** | every team with a panel | a green board that is watching a stream nobody writes to any more | | **cost attribution by prefix** | finance and the platform team | spend appears to move between domains for no reason | | **runbooks and wiki pages** | everyone, eventually | an incident is handled against a stream that is not the live one | That list is the answer to the question. Nothing in it lives in the broker, which is why an engineer who has only ever created streams thinks a rename is an afternoon. ## Why an alias is not a rename Some platforms let you keep answering on the old name — an alias, a routing rule, a second address for one stream. It is genuinely useful: clients can be moved in their own time instead of all at once. But three things survive it: - the rules above stay keyed to whichever name each one was written against, so the ambiguity now has to be maintained in two places; - the alias itself becomes an estate object with an owner and an end date, and ending it is a second migration; - anything that enumerates streams — a sweep, a cost report, an inventory — now sees two entries for one thing and has to be taught the relationship. An alias buys time. It does not make the change an edit. ## What stays behind On platforms where records remain readable after delivery, everything already written stays under the old name. It is not moved, re-keyed or re-addressed; it sits there until retention removes it, and any reader that needs that history has to be pointed at the old name deliberately. On queue-shaped platforms where a delivered message is gone, there is less to leave behind, and the question becomes whether anything is still undelivered when the writers stop. Either way the old stream has to keep existing for a while, which is why the delete is always later and separate. ## Where platforms differ - **Rename support**: absent on most, alias-shaped on some, and genuinely present on a few where the name is a mutable attribute of a registered object. - **Grant matching**: prefix patterns on some platforms, exact names on others, and on a third kind the grants belong to the named space rather than the stream, so moving a stream between spaces is the expensive case instead. - **Settings inheritance**: some platforms let a replacement inherit from its space, so fewer settings have to be restated; others stamp creation-time defaults and leave them. ## The practical consequence 1. Treat the name as an interface, decided before the first record and priced afterwards. 2. Get the environment segment right at creation, because that is the one whose mistake is actively dangerous rather than merely ugly. 3. When a rename is genuinely justified, budget the inventory above — not the broker call — and find the rules by searching for the old string everywhere, not by asking who remembers writing one. 4. Write new rules against the prefix rather than the full name, so the next change is smaller than this one.