System Design Cases
Elasticsearch / OpenSearch
Elasticsearch / OpenSearch concept page: distributed Lucene cluster (3 master + 3 data + coord), inverted index, sharding, query/fetch phases, aggregations, split-brain, mapping explosion
Elasticsearch: shard routing, near-real-time search and safe coordination
Elasticsearch — distributed search engine with a primary/replica shard model. Correctness requires not смешивать indexing ACK, Lucene refresh visibility, translog/recovery и master-eligible voting.
Корректная модель
- Index acknowledgement, translog durability and search refresh visibility are separate.
- A primary shard orders each document operation; replicas apply the resulting operation asynchronously/concurrently with safeguards.
- Search can fan out and return partial shard failures; clients must inspect response semantics.
- cluster.initial_master_nodes is only for first bootstrap and must not be reused on restarts.
Границы и компоненты
| Компонент | Ответственность |
|---|---|
| Index and Search Client | Отправляет writes, GET/search и consistency preconditions. |
| Coordinating Node | Маршрутизирует document write или scatter/gather search. |
| Primary Shard | Проверяет mutation и назначает sequence number. |
| Replica Shard A | Применяет ordered replication operation и может обслуживать search. |
| Replica Shard B | Независимая shard copy; не обязана ACK при weaker setting. |
| Master-Eligible Quorum | Публикует cluster state и allocation; не находится в per-document data path. |
| Snapshot Repository | Recoverable backup boundary, отличный от shard replicas. |
Сценарии
Primary-ordered document indexing
The coordinating node routes by document ID to one primary. The primary validates and assigns ordering metadata before parallel replica requests.
Проверяемый исход: The response reports actual successful/failed shard copies; it is not described as a mandatory 3-of-3 quorum.
Near-real-time search visibility
A successful index response does not imply immediate search visibility. Refresh opens a new segment; real-time GET and search have different paths.
Проверяемый исход: Caller selects refresh=wait_for only when its latency/throughput trade-off is justified.
Optimistic concurrency conflict
A client updates only if both if_seq_no and if_primary_term match the version it read. Another committed mutation makes the stale precondition fail.
Проверяемый исход: Lost update becomes an explicit 409/re-read decision rather than last-writer-wins by accident.
Safe cluster recovery
A formed cluster retains its cluster UUID. Restarting nodes discover that cluster; they never reuse initial bootstrap settings. Lost shards recover from peers or verified snapshots.
Проверяемый исход: No accidental second cluster is bootstrapped, and replicas are not mistaken for backups.
Failure, concurrency и replay checklist
- Use seq_no plus primary_term for conditional writes.
- Treat replica count as availability/read scale, not backup retention.
- Monitor unassigned shards, rejected writes, refresh/merge pressure and partial search failures.
- Verify snapshot restore and remove first-bootstrap configuration after formation.
Формулы, units и допущения
- Primary shard count fixes maximum routing fan-out and per-shard data size until reindex/split strategy; more shards add metadata and coordination overhead.
- Search latency is dominated by the slowest required shard response plus reduce time; average shard latency is insufficient.
- refresh interval is a configured visibility cadence, not a durability SLA or universal one-second guarantee under every setting.
Числа выше — учебные inputs или размерностные формулы. Их нельзя выдавать за benchmark или SLA конкретного продукта.
Связанные темы
[CONCEPT]database-replication-deep
Первичные источники
- https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-replication.html
- https://www.elastic.co/docs/manage-data/data-store/near-real-time-search
- https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control
- https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-bootstrap-cluster.html
Scope note
Диаграмма показывает причинные границы и recovery contracts, а не скрытую реализацию конкретного managed-сервиса. Любая stronger guarantee действует только в явно названной transaction/checkpoint/acknowledgement boundary.