The 30 second answer
I shard by document id inside each index and usually isolate markets or market groups so one region's load cannot take others down. Writes go through aliases so reindex and blue-green upgrades are atomic. Primaries are sized for growth; replicas buy read capacity and availability. Analyzers are per language. I call out over-sharding and high-cardinality aggregations as self-inflicted outage risks.
Document partitioning. Elasticsearch (and Lucene-based engines generally) typically use local secondary indexes: each shard holds a subset of documents and its own inverted index. A query fans out to relevant shards and the coordinating node merges hits. DDIA contrasts local vs global secondary indexes: local makes writes cheap and reads scatter/gather; global makes term lookups cheaper but complicates writes.
Market isolation (Opinion + public lesson). For multi-country catalogs, prefer separate indices (or clusters) per market or market group behind aliases. Zalando's ES 8 migration post describes country indices behind aliases, write aliases (_write), numeric suffix index names, and multi-cluster deployment. Their Dec 2025 incident post notes market-grouping isolation containing blast radius when one cluster was overloaded. The 2022 Elasticsearch Berlin meetup talk (Girish Chandrashekar) described markets in separate indices and hardware profiles grouped by traffic — treat 2022 sizing numbers as historical, not current capacity planning.
Aliases and blue/green. Clients should talk to aliases, not raw index names, so you can reindex and swap. Zalando's ES 7→8 migration used blue/green via reindex/snapshot, shadowed intake and query traffic (Skipper), then gradual cutover — with a routing bug that briefly left two indices behind one alias and duplicated products. Mention aliases as both a feature and an operational footgun.
Vectors. If you store embeddings for ANN, plan for refeed on model change. Zalando's arXiv ranking paper states new item embeddings go through a Kafka intake into Elasticsearch and that a new model needs a full refeed with blue-green switch of embeddings.
What not to invent. Public Zalando posts do not document production primary/replica counts for core search. Do not invent shard counts; explain the sizing method instead (target shard size, heap, query fan-out, refresh cost).
Sources:
- Elasticsearch — Index aliases
- Elasticsearch — Scalability and resilience (and related sizing guides)
- DDIA — sharding with secondary indexes (study map theme 4)
- Zalando Engineering — Migrating From Elasticsearch 7.17 to 8.x
- Zalando Engineering — The Day Our Own Queries DoS'ed Us
- arXiv 2409.02856