Most search boxes exist to answer one question: what matches the words I typed? That's the right question for a library catalog. It's the wrong question for a nutrition app.
When a user opens the recipes page in Appetec, the words they type are the least interesting part of the request. What actually matters is invisible: calories left today, what they've cooked week after week without thinking about it, whether they're vegan, and whether they've already blown their budget by dinner. A search engine that ignores all of that will happily return recipes that match — and just as happily sabotage the reason the user opened the app. This is the architecture behind a pattern built to close that gap: relevance that's right for this person, right now.
Why Text Match Alone Isn't Enough
The pattern applies whenever the same query should return different results for different users — when "best" depends on context the user never typed, and when the catalog you own is smaller than the catalog your users expect. Personalized recipe search treats relevance as a blend of three signals instead of one:
| Signal | What It Captures |
|---|---|
| Text | What the user typed — or, in meal-scan mode, what was detected on their plate |
| Goal fit | How well a recipe fits the calories the user has left for this meal, today |
| Habit | How often this specific user actually eats this recipe |
A naive engine sees only the first row of that table. This pattern fuses all three into a single ranked list, then backfills from an external source whenever the local catalog runs thin — quietly growing that catalog every time it does. The result feels less like querying a database and more like a friend who already knows your kitchen and your diet.
How the Pipeline Is Put Together
The system runs as a retrieval pipeline with a personalization layer in front and a self-healing catalog behind it.
Two search engines, one contract. Elasticsearch is primary: fuzzy typo tolerance, English stemming ("grill" finds "grilled"), weighted relevance scoring. If it's ever unavailable, the same query falls through to a MongoDB search honoring the same filters and personalization rules. Search degrades under failure; it never disappears.
The layer users feel but never see. Before results return, three things reshape the list. Calorie budget is computed from the daily target minus what's logged, boosting recipes that fit whatever window is left — and if the user has blown past their target, the list quietly re-sorts lowest-calorie-first, nudging toward recovery instead of indulgence. Eating history distills the last 60 days of meal logs into a "what you actually eat" map, keeping favorites one tap away on page one. Diet preference — veg, vegan, non-veg, plus two dozen finer tags like keto, gluten-free, and high-protein — filters and re-ranks everything underneath.
A catalog that grows itself. When local results run thin, the pipeline pages into an external source, FatSecret, stitching those results into the same infinite-scroll feed with no visible seam. It then writes those external recipes back into the local catalog, using an LLM to classify each as veg, non-veg, or vegan, so it's correctly personalizable next time — the same instinct behind a hybrid retrieval architecture we've applied elsewhere, where local and external results need to feel like one system.
Three caches, three jobs. Combined result sets, the per-user habit map, and external-API responses each carry their own independent lifetime, so a personalized, multi-source query still returns at roughly the speed of a single plain lookup.
The Trade-offs Worth Naming
None of this came for free, and being honest about the cost is part of what makes the pattern trustworthy rather than just clever.
Relevance was made deliberately un-neutral. A pure text-relevance ranking is "fair" in a way that's actively unhelpful here. Results are biased toward goal fit and habit on purpose, because a slightly-less-textually-perfect recipe that fits someone's budget and taste is the better answer. "Why did this rank first?" becomes a product decision, not a search-engine default — which is why those weights live in application code, not an unowned config file.
Owning the whole catalog wasn't the goal — owning the right part of it was. The extremes considered were a fully curated catalog (high quality, narrow breadth) or a full proxy to an external API (unlimited breadth, zero control, zero personalization). The system splits the difference: lead with owned and user-authored recipes, backfill externally when needed, and absorb what gets backfilled — trending, over time, toward owning exactly what users actually search for.
Resilience was chosen over peak efficiency. Two full search engines cost more to operate than one — the same resilience-first thinking behind most of our backend decisions. That cost was accepted deliberately: recipe search is core, daily-use functionality, where degraded search is a minor annoyance but missing search is a broken app.
Personalization costs predictability. Results genuinely differ by time of day, calories consumed, and history — even for the same user at breakfast versus dinner. That's intended, but it raises the bar for testing and support: "it works on my phone" stops meaning much when correctness is defined per-user, per-moment.
When This Pattern Fits — and When It Doesn't
It's worth being clear about where this pattern shouldn't be reached for. It earns its complexity when results should genuinely differ per user based on context they never typed, when the owned catalog is smaller than what users expect but can be enriched externally, when the feature is frequent enough that graceful degradation matters more than minimal infrastructure, and when "relevance" legitimately includes signals beyond text.
It's the wrong tool when results are identical for every user — a public docs search, a SKU lookup — where personalization adds cost with no payoff. It's unnecessary when the catalog is small and stable enough that a single engine with plain filtering suffices, and it works against you anywhere strict, identical, fully explainable ranking is a hard requirement.
The Actual Job
Retrieval quality here is treated as a personalization problem, not just a matching problem. A recipe search that's textually perfect while ignoring that the user is vegan, already over budget, and has cooked the same five dinners all month technically worked and practically failed. The job was never to find recipes that match the query — it's to surface the recipe this person should cook next. Every layer of this architecture, from the dual search engines to the quiet re-sort when someone's over budget, exists to close that gap.
If you're weighing a similar build-vs-blend decision for search or retrieval in your own product, we're happy to talk it through.
Other Blogs
1. Scaling a Digital Health Platform with Microservices
