In what order does Elasticsearch merge composed_of component templates into an index's configuration?

## Why composition exists Before composable templates, sharing configuration between index families meant copying JSON. Component templates fix that: you store reusable fragments once (`PUT _component_template/base-settings`, `PUT _component_template/common-fields`) and index templates assemble them with `composed_of: ["base-settings", "common-fields"]`. The fragments have exactly the same shape as an index template's `template` block — `settings`, `mappings`, `aliases` — but carry no `index_patterns` and no `priority`, because they never match anything themselves. ## The precedence chain For an index created under a winning index template, the effective configuration is built in this order, each layer overriding the ones before it: 1. every component template in `composed_of`, **in array order** — first entry lowest precedence, last entry highest; 2. the index template's own `template` block; 3. `settings`, `mappings` and `aliases` passed in the create-index request itself. So `composed_of: ["a", "b"]` means b wins over a, and the template's inline block wins over both. Reordering the array is a real configuration change, not cosmetics — a reviewer who treats `composed_of` as a set rather than a list will approve a broken diff. ## Merging is per key, not per block The layers do not replace one another wholesale. Merging happens at the finest granularity the structure allows: - **Settings** merge key by key. A component that sets only `index.number_of_replicas` leaves an earlier component's `index.refresh_interval` intact. - **Aliases** merge by alias name; two components can each contribute a different alias. - **Mappings** merge field by field. `properties` objects combine recursively, so a "common fields" component contributing `@timestamp` and `service.name` composes cleanly with a domain component contributing `order.total`. Where the *same* field path is defined twice, the higher-precedence layer's definition is the one that survives. The pieces people get wrong are the array-valued parts of a mapping — `dynamic_templates` most of all. Do not reason about those from first principles; compose the template and read the result from the simulate API, because a dynamic template that silently disappeared or silently doubled will only show up as strangely mapped fields much later. ## Component templates are inert on their own Storing a component template changes nothing about any index. It is a fragment sitting in the cluster state waiting to be referenced. This is a frequent support question: "I added the field to the component template and new indices still do not have it" — almost always because no index template's `composed_of` mentions it, or because the index template that *does* mention it lost the priority contest to another one. The inverse protection also exists: `DELETE _component_template/<name>` is rejected while any index template references that component. You must edit or delete the referring index templates first. That ordering constraint is worth knowing before you write a teardown script. From 8.7, `ignore_missing_component_templates` lets an index template list a component that does not exist yet without failing — the pattern Elastic's own integrations use to leave a hook for an optional user-supplied override component. ## A worked example Suppose `base` sets `number_of_shards: 1`, `regional` sets `number_of_shards: 3`, and the index template's inline block sets `number_of_shards: 5`, with `composed_of: ["base", "regional"]`. A new index gets **5** shards: `regional` beats `base` by position, the inline block beats both. If the operator then issues `PUT /orders-eu-1 {"settings": {"number_of_shards": 2}}`, the index gets 2, because the request body is the outermost layer. That last case is worth flagging in review. An explicit create-index body silently defeats the whole template stack, which is fine for a one-off experiment and terrible in automation, because the cluster now contains an index whose configuration cannot be explained by reading any template. ## How to design the layering Keep the layers semantic and few. A common working split is: one component for cluster-wide index settings, one for the shared field schema, one per team or domain for its own fields, and — highest precedence — a small override component reserved for emergencies. Deep chains of six or seven components make every question of the form "where does this setting come from?" into an archaeology exercise. Whatever the depth, the answer to that question always comes from the simulate API rather than from reading the JSON, because only the simulate output reflects the real merge.