Why is number_of_shards fixed at creation in Elasticsearch while number_of_replicas can change live?

## The routing formula is the reason When you index a document, the coordinating node has to decide which primary shard owns it. It does that arithmetically, not by lookup: it hashes the routing value — the document `_id` by default, or an explicit `_routing` value if you supplied one — and reduces the hash against the index's shard configuration. In the simplest form this is `shard = hash(_routing) % number_of_primary_shards`. Since Elasticsearch 6/7 the formula also involves `index.number_of_routing_shards`: the hash is taken modulo the routing-shard count and then divided by a routing factor (routing shards divided by primary shards), which is exactly what makes a later `_split` able to move whole groups of routing shards into new primaries without re-hashing. The key property is that the primary shard count is an *input* to that formula. Nothing on disk records "document X lives on shard 3"; the shard is recomputed from the id every time. Change the count and every previously indexed document is now computed to live somewhere it does not. Reads by id would miss, updates would create duplicates on the newly-computed shard, and deletes would silently no-op. There is no cheap in-place fix, because fixing it means physically moving most documents — which is precisely what a reindex does. ## Final settings versus dynamic settings Elasticsearch classifies index settings as *final* (set at creation, never updatable), *static* (updatable only on a closed index) or *dynamic* (updatable on a live index). `index.number_of_shards` and `index.number_of_routing_shards` are final; a `PUT /my-index/_settings` naming them fails with an error saying the setting cannot be updated. `index.number_of_replicas` is dynamic, and so are the settings people tune day to day, such as `index.refresh_interval`. ## Why replicas are different A replica shard is a byte-level copy of a primary's Lucene segments, kept in sync by the replication of every write. It participates in search — the coordinating node may route a shard-level search request to the primary or to any in-sync replica — but it plays no part in deciding where a document belongs. Increasing `number_of_replicas` therefore only means: the master allocates new unassigned replica shards to nodes, and peer recovery copies segments (plus replays translog) from the primary until each copy is in sync. Cluster health goes yellow while those copies are initializing and back to green when they are in sync. Decreasing the count simply deletes copies, which is instantaneous. Replicas are not free, though. Each one multiplies disk usage, must apply the same indexing work as the primary, and consumes heap and file handles like any other shard. They buy availability (a lost node does not lose data) and search throughput (more copies to fan queries across). ## What to do when the primary count is wrong Because the number is frozen, the practical answers are all "make a new index": - **Reindex** into a freshly created index with the right shard count, then swap an alias. Always correct, but re-analyses and re-indexes every document, so it is the most expensive option. - **`_split`** the index into more primaries. The source must be read-only; the target count must be a multiple of the source count and compatible with `number_of_routing_shards`. - **`_shrink`** the index into fewer primaries. The source must be read-only, green, and a copy of every shard must be on a single node; the target count must divide the source count. - **Rollover** — for append-only time-series or log data, stop trying to size one index for all time. Roll to a new backing index periodically (by age, doc count, or primary shard size) and set the shard count in the index template. Each new index gets today's best answer, and yesterday's mistake ages out with retention. ## Interview framing The answer interviewers want is the causal one — routing arithmetic, not "because Elasticsearch says so". A strong candidate then adds the design consequence: because the number is immutable, you either invest in a quick sizing benchmark up front, or you adopt an index-per-period pattern so the decision is revisited automatically and no single index has to be right forever.