Design your search cluster
Every Elasticsearch deployment is a deliberate trade across shard count, replica count, refresh interval, scoring strategy, and ILM tiering — and the right answer for an e-commerce catalog is wrong for a security-analytics archive even though the primitives are identical.
The same primitives — shards, replicas, refresh, scoring, tiers — configure radically different deployments. The capstone is choosing them deliberately, with each choice traceable to the scene that justifies it.
Scene 12
Design your search cluster
- Watch
- Try it
- Predict
- Capture
Three workloads, three honest configurations. The canvas snaps to the defaults for each archetype; read the verifier rows — every ✓ cites the scene that justifies it.
Highlighted lines are the ones running in the diagram right now.
# 5M product catalog · interactive browse · ranking is part of SLO# primary_shards = 2 (scene 5: small corpus, few shards)# replicas = 1 (scene 6: HA + read fan-out)# refresh = 1s (scene 4: live catalog UI)# search_type = dfs_query_then_fetch (scene 9: stable rankings# across reindex)# terms_agg = default shard_size (scene 10: not the bottleneck)# ILM = off (scene 11: products don't age out)
Where this sits in Build a distributed search engine (Elasticsearch / OpenSearch style)
Scene 12 of 12. Capstone: pick e-commerce, logs, or security analytics and configure shards, replicas, refresh, scoring, and ILM — the verifier traces every ✓/✗ back to the scene that earned it.
All 12 scenes in Build a distributed search engine (Elasticsearch / OpenSearch style) · Every curriculum