Mapping Changes, Reindex & Aliases

## What an alias actually is An Elasticsearch index alias is a **pointer stored in cluster state**, not a copy of data. Creating an alias moves no bytes and costs no disk. Any API that accepts an index name — search, index, delete, bulk, aggregations — accepts an alias name and resolves it to the concrete index or indices behind it at request time. The motivating fact is that **an Elasticsearch index cannot be renamed, and its mapping is largely immutable**. Changing a field's type, changing an index-time analyzer, or changing the shard count all require creating a *different* index and copying documents into it. If every application, dashboard and script names `products` directly, every one of them must be edited and redeployed at the moment the new index is ready. That turns a routine mapping change into a cross-team release. ## The indirection convention The standard production convention is: **no client ever names a concrete index.** You create `products-v1` (or `products-000001`) and give it the alias `products`. Clients only know `products`. When the mapping must change you create `products-v2`, populate it, verify it, and repoint the alias. It costs nothing to add the alias on day one and it is nearly impossible to add later without a coordinated redeploy, which is why interviewers treat "I would have put an alias in front of it from the start" as the expected answer. ## The atomic swap Repointing is done through the `_aliases` API, which takes an `actions` array applied as one cluster-state update: ``` POST /_aliases { "actions": [ { "remove": { "index": "products-v1", "alias": "products" } }, { "add": { "index": "products-v2", "alias": "products" } } ] } ``` All actions in one call succeed or fail together, so searches never see a window where `products` is missing or ambiguous. Doing the same thing as two separate calls — delete the alias, then create it — leaves a gap in which every query fails with `index_not_found_exception`. That distinction is the whole point of the API and is a common interview probe. The same call can carry a `remove_index` action, which deletes the old index in the same atomic update; in practice you normally keep the old index for a rollback window instead. ## Read aliases versus write aliases An alias may point at many indices. For **searches** that is a feature: one alias fans a query across `logs-2026-06`, `logs-2026-07` and so on. For **writes** it is ambiguous — Elasticsearch cannot guess which index a new document belongs in, so an index request through a multi-index alias is rejected unless exactly one of the backing indices is marked `"is_write_index": true`. That flag is what lets a rollover-style alias accept writes into the current index while still serving reads from all of them. A common pattern separates the two concerns explicitly: a read alias `products` over one or more indices, and a write alias `products-write` pointing at exactly one. During a cutover you can then flip reads and writes at different moments. ## Filtered and routed aliases An alias can attach a `filter`, so every search through it is implicitly ANDed with that query — a cheap tenant or category view over a shared index. It can also pin `routing` (or `index_routing`/`search_routing`) so requests through it hit a single shard. A filtered alias is a **convenience, not a security boundary**: a caller who is allowed to query the underlying index directly simply bypasses the filter. Real isolation needs the security features' document-level security, or separate indices. ## Practical gotchas - Aliases are cluster state; thousands of them are not free, though normal usage is nowhere near a problem. - `_reindex` does **not** copy aliases to the destination index — you add them yourself as part of the swap. - Deleting an index silently deletes its aliases with it. - An alias name may not collide with an existing index name. - Kibana index patterns, ingest destinations and Logstash outputs should all be pointed at the alias too, or the indirection leaks. ## Why interviewers ask it The alias question is really a proxy for "have you ever changed a mapping in production?" The candidate who has says *alias in front of versioned indices, atomic swap, keep the old one for rollback* without being prompted.