Combine the decisions into a testable catalog design, from requirements to recovery.
course-products examples use the teaching mapping and product from chapter 5, “Mapping and field types”. Exercise walkthroughs below use the trainer’s separate public dataset.
- From scenarios to documents
- Contract and quality
- Final design assignment
Combine the decisions into a testable catalog design, from requirements to recovery.
The course targets Elasticsearch 9.4.3. Exercise examples use the public products dataset; other requests illustrate separate teaching indices and may require setup or privileges unavailable in the trainer. Responses are shortened fragments; scores may vary. Check deployment and license requirements for advanced features.
From scenarios to documents
List SKU lookup, descriptive discovery, filtering and offer comparison. Define expected results and mandatory constraints for each. Choose document boundaries, exact and full-text fields, nested scopes and update rules afterward. A search document must serve real queries; copying relational tables is not automatically a good design.
Check your understandingContract and quality
Specify input, mandatory filters, sorting, cursors, counts and errors. Define ranking and relaxation policies separately. Prepare judged queries and regressions for SKUs, missing fields, multiple offers and zero results. Set p95, response-size and synchronization-lag limits.
Check your understandingFinal design assignment
Design a million-product catalog with two languages and multiple sellers. Include mapping and analyzers, five query scenarios, facets, quality metrics and update delivery. Describe analyzer-change reindexing, alias cutover and snapshot recovery. Check that fallback preserves access, retries avoid duplicates, offers remain associated, quality is measured and restoration is testable. Justify tradeoffs instead of adding settings speculatively.
The final query combines candidates, constraints and analytics; scenarios validate its quality.
{
"size": 10,
"query": {
"bool": {
"must": [
{
"match": {
"name": "wireless headphones"
}
}
],
"filter": [
{
"term": {
"in_stock": true
}
},
{
"range": {
"price": {
"lt": 200
}
}
}
]
}
},
"aggs": {
"brands": {
"terms": {
"field": "brand",
"size": 10
}
}
},
"_source": [
"name",
"brand",
"price"
]
}How to read this result
The final query combines candidates, constraints and analytics; scenarios validate its quality.
Catalog reasoning example
A design should let another developer reproduce field/analyzer choices, mandatory filters, cursor behavior and count meanings. Record the reason and validation method for disputed settings. Avoid maximum complexity by default: if lexical retrieval meets requirements, vectors must demonstrate additional value. List load and freshness assumptions so changes trigger a review of the relevant decisions.
Check your understandingCheck your understanding
Answer before expanding each explanation.
1. Where should design start?
With user scenarios, quality criteria and constraints.
2. How do you choose a document boundary?
From retrieval and update needs, considering denormalization and nested costs.
3. What validates a migration?
Change catch-up, data checks and search regressions before cutover.
4. Which metrics complement NDCG?
Latency, failures, freshness and processing cost.
5. When is a design ready to implement?
When contracts, tradeoffs, quality checks and failure/recovery procedures are defined.
Module case study: Modern search and system design
A client needs two-language semantic discovery and exact SKU search. Design two retrieval branches and a comparison with a lexical baseline. Explain inference budgets, access constraints and behavior during model outages.
Assessment criteria
Retain exact lookup, evaluate hybrid results on judgments, enforce access in all branches, define timeout/lexical fallback and verify deployment/license support.
Key takeaways
- With user scenarios, quality criteria and constraints.
- From retrieval and update needs, considering denormalization and nested costs.
- Change catch-up, data checks and search regressions before cutover.
- Latency, failures, freshness and processing cost.
- When contracts, tradeoffs, quality checks and failure/recovery procedures are defined.
Official reference
Ready to put this into practice?
Confirm reading to save your place. Reading and exercise progress are tracked separately in this browser using your guest cookie.