Elasticsearch Indexing, Relevance Tuning, and Performance Issues in a Dynamic Restaurant Menu Website

I am managing a restaurant menu website that relies heavily on Elasticsearch to power search functionality across menu items, categories, ingredients, dietary tags, and promotional offers. The dataset includes hundreds of items with frequently changing prices, availability flags, seasonal promotions, and location-specific variations. While Elasticsearch has significantly improved search speed compared to our previous database queries, we are facing multiple challenges related to indexing consistency, relevance tuning, and performance under real-world traffic. The search feature is central to user experience, so even minor inaccuracies in results or delays in indexing can directly impact customer engagement.

One of the major issues involves near real-time indexing and data synchronization. Menu items are updated frequently sometimes multiple times per day due to pricing changes, temporary promotions, or stock availability. We push updates to Elasticsearch whenever changes occur, but there are cases where search results reflect outdated data for several minutes after updates are made. Although we understand Elasticsearch is near real-time by design, the delay is noticeable to users who search immediately after changes are applied. I am trying to determine whether this is due to refresh interval configuration, indexing throughput limits, or our bulk update strategy, and I would appreciate recommendations for optimizing index refresh behavior without harming cluster performance.

Relevance tuning is another significant challenge. Users may search for general terms such as “burger,” “chicken,” or “spicy,” but they also search for specific ingredient combinations, dietary filters, or promotional labels. Our current mapping uses a combination of analyzed text fields, keyword fields, and multi-fields for sorting and filtering. However, some search queries produce unexpected ranking results, where less relevant items appear above more appropriate matches. I am exploring custom analyzers, synonym filters, boosting certain fields (such as item name over description), and possibly function scoring based on popularity metrics, but finding the right balance has been difficult. Practical advice on structuring mappings and scoring strategies for menu-style datasets would be extremely helpful.

Performance under load presents additional concerns. You can check culver menu as well. During peak traffic especially when new promotions launch the search API experiences noticeable latency spikes. We are currently running a small cluster with multiple shards per index, but I am unsure whether the shard count is optimal for our dataset size and query patterns. Some queries combine full-text search with multiple filters (e.g., price range, dietary tag, category), and aggregations for filtering facets are included in the same request. These compound queries may be contributing to increased response times. I would appreciate guidance on shard sizing, query optimization, caching strategies, and whether restructuring indices by category or location would improve performance.

Another complication arises from multilingual support and partial matching behavior. The menu includes item names and descriptions that may contain regional variations, abbreviations, or alternative spellings. Users often type incomplete words or misspell item names, so we have experimented with edge n-grams and fuzzy matching. While this improves match coverage, it also increases index size and occasionally produces overly broad results that reduce relevance precision. Finding the correct balance between recall and precision especially in a consumer-facing search experience has been challenging. Insights into best practices for implementing autocomplete, fuzziness, and language analyzers for similar use cases would be appreciated.

Finally, I am looking for recommendations on monitoring, scaling, and long-term maintainability of our Elasticsearch setup as the website grows. We anticipate expanding to additional locations, adding more items, and introducing personalization features that may affect scoring logic. Ensuring that the cluster remains stable, search remains fast, and indexing remains reliable is critical for future scalability. Any advice from the Elastic community regarding architecture patterns, index lifecycle management, scaling strategies, and performance diagnostics for dynamic, frequently updated datasets would be greatly appreciated. Sorry for long post

The refresh interval is by default 1 seconds, so a delay of several minutes for it to take effect IMHO either means 1) the refresh interval is set incorrectly (easy to check via API) or 2) refreshes are very slow (potentially due to very slow storage) or 3) that the issue is in the processing of updates before they reach Elasticsearch.

It would help if you could provide some information about the number of indices in the cluster as well as the number of primary shards and the average and maximum size of the shards. For search use cases shard sizes between 10GB and 30GB should be fine, so for your use case I would expect reasonably small shards and therefore suspect a single primary shard per index is ideal.

I will leave the questions around best practices for relevance tuning for someone else.