| Query<\/th> | Logged out<\/th> | Logged in<\/th><\/tr><\/thead> | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
maggi noodles<\/code><\/td> |
This week Zepto published a 15-minute engineering deep-dive called “Building Search for a 10-Minute World.” It is genuinely good architecture writing. Llama 3-8B for query correction, a custom bi-encoder for semantic retrieval, Mixture of Experts ranking, a four-stream exploit\/explore recall design. The kind of post that gets bookmarked.<\/p>\n\n\n\n
Then I opened zepto.com without logging in and typed five queries. Three of them returned a blank page.<\/p>\n\n\n\n
Then I logged in and typed the same five queries. All five worked perfectly.<\/p>\n\n\n\n
This post is the teardown: what fails for guests, why their own architecture blog says this should be impossible, and why the broken path is the one that matters most for their business.<\/p>\n\n\n\n
All queries were run at the same dark store (Arjun Nagar, Delhi), on 11th June, with products in stock. Each query was run twice: once logged out, once logged in.<\/p>\n\n\n\n Look at the failure pattern. One missing apostrophe. One extra apostrophe. One English stopword. For a guest, each of these kills a query for a brand sitting in stock at the store. Log in, and the exact same characters return a full page of products.<\/p>\n\n\n\n A side note that still makes me laugh: on the guest path, For reference, I ran the same queries on Swiggy Instamart at the same location, also logged out. Every single one returned correct results. Whatever Zepto’s guest path is missing, their competitor does not require an account to provide it.<\/p>\n\n\n\n And one more detail. Zepto’s zero-results page for This is the genuinely interesting part.<\/p>\n\n\n\n Zepto’s architecture post is explicit about the separation of concerns in their search stack. The retrieval service, search-platform, is described as a pure function that “knows nothing about users.” No delivery address, no order history, no experiment cohort. It receives a query, a city identifier, and eligible delivery hub IDs, and returns candidates. Personalization, session data, and experiment assignment all live downstream, in the orchestration layer, where candidates get ranked and assembled into a page.<\/p>\n\n\n\n Take that description at face value and walk through my results. Same query string. Same city. Same store, therefore the same hub IDs. By their stated design, retrieval inputs are identical for my guest session and my logged-in session, so the candidate set must be identical too. Personalization can reorder candidates. It cannot create candidates out of a recall that returned zero.<\/p>\n\n\n\n Yet logging in took three queries from a blank page to a full one. Recall itself changed with login status, which is exactly what the published architecture says cannot happen.<\/p>\n\n\n\n I can think of three explanations, and none of them flatter the blog:<\/p>\n\n\n\n I do not know which it is, and I would genuinely welcome a correction from anyone on the Zepto search team. But from the outside, the observable fact is: the search described in the blog is not the search a new user gets.<\/p>\n\n\n\n It is tempting to file this under “edge case.” It is the opposite. The logged-out experience is Zepto’s front door:<\/p>\n\n\n\n These are precisely the sessions where search quality decides whether an account gets created at all. A returning logged-in user who hits a bad result will retype and move on; they have already committed. A guest who types “maggi’s noodles”, sees “could not find any products”, and gets shown a competitor’s ad instead has every reason to conclude the catalogue is thin and close the tab. The broken path is pointed directly at customer acquisition.<\/p>\n\n\n\n Whatever the guest pipeline is, its failure modes are textbook. All four of the following are decades-old search engineering, none involve an LLM, and the logged-in path clearly has some or all of them.<\/p>\n\n\n\n Zepto runs on OpenSearch, which ships with built-in typo tolerance: set Their blog argues that “standard edit-distance correctors fail entirely here” because vernacular queries like “kothimbir” share no characters with “coriander.” True, and a good argument for the LLM layer. But the guest path then fails on Mature search systems have a zero-results recovery path: if the full query finds nothing, drop the weakest token and retry, repeating until something matches. The guest path has no ladder. One out-of-vocabulary token vetoes the whole query, even when the remaining tokens exactly match a stocked brand. A query containing the literal string “mother dairy” returned nothing while Mother Dairy products sat on the shelf.<\/p>\n\n\n\n The blog’s biggest investment is a custom bi-encoder that retrieves by meaning instead of spelling. Vector search has a useful property: it cannot return zero results, there is always a nearest neighbour. The floor of any search system should be what a naive substring match would return. Unrelated to the guest issue, one more design observation from the blog. Zepto says full result caching “doesn’t work at all” because personalization, session signals, and experiment assignment make the cardinality of valid pages too high. But by their own architecture, all that state lives in the orchestration layer. The retrieval service is stateless: query, city, and hub set in, candidates out. That is a pure function, and pure functions are perfectly cacheable.<\/p>\n\n\n\n For head queries, which they admit are stable and which dominate their traffic, a short-TTL candidate cache keyed on query, city, and hub set would skip lexical recall, semantic ANN, and all four candidate streams. Stale inventory does not matter because their own Product Assortment Service re-resolves ground truth downstream anyway. They built the perfect cacheable boundary, then wrote a paragraph about why caching is impossible.<\/p>\n\n\n\n Ironically, the guest finding strengthens this point. If guest search must remain fully anonymous anyway, it is the most cacheable traffic they have.<\/p>\n\n\n\n I have spent 14 years building and scaling search systems, including Elasticsearch clusters past 500 million documents, and the meta-lesson here is one I keep relearning.<\/p>\n\n\n\n An architecture blog describes the system at its best, on its best path, for its best-instrumented users. The product your next customer experiences may be a different system entirely, an older pipeline, a default config, a path nobody dogfoods because every employee is logged in. Zepto’s engineers almost certainly never see what I saw, because Zepto’s engineers all have accounts.<\/p>\n\n\n\n Test your product the way a stranger meets it. Logged out, on the web, with a typo. That is the search system you actually shipped.<\/p>\n\n\n\n Methodology: all queries tested on 11th June 2026 at the Arjun Nagar, Delhi dark store, each run in a logged-out session and a logged-in session. Logged-out failures were reproduced across multiple sessions. Zepto’s original post, which is worth reading despite everything above, is here: https:\/\/blog.zepto.com\/building-search-for-a-10-minute-world-43b1992f5dca<\/a>. If you work on the Zepto search team and any of my inferences are wrong, I would genuinely love the correction, that is what the comments are for.<\/em><\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":"Query<\/th> Logged out<\/th> Logged in<\/th><\/tr><\/thead> maggi noodles<\/code><\/td>Perfect<\/td> Perfect<\/td><\/tr> maggis noodles<\/code><\/td>0 results<\/strong><\/td> Works<\/td><\/tr> maggi's noodles<\/code><\/td>0 results<\/strong><\/td> Works<\/td><\/tr> mother dairy dudh<\/code><\/td>Works<\/td> Works<\/td><\/tr> dudh of mother dairy<\/code><\/td>0 results<\/strong><\/td> Works<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n ![\"\"](\"https:\/\/geekabhi.com\/blog\/wp-content\/uploads\/2026\/06\/Screenshot-2026-06-11-220151-1024x570.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekabhi.com\/blog\/wp-content\/uploads\/2026\/06\/Screenshot-2026-06-11-215724-1024x519.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekabhi.com\/blog\/wp-content\/uploads\/2026\/06\/Screenshot-2026-06-11-215323-1024x666.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekabhi.com\/blog\/wp-content\/uploads\/2026\/06\/Screenshot-2026-06-11-225315-1024x548.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekabhi.com\/blog\/wp-content\/uploads\/2026\/06\/Screenshot-2026-06-11-225419-1024x562.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/geekabhi.com\/blog\/wp-content\/uploads\/2026\/06\/Screenshot-2026-06-11-225507-1024x532.png\")
<\/figure>\n\n\n\nmaggis<\/code> alone works fine (a popular enough typo to be handled), but maggis noodles<\/code> returns nothing. Adding a correct, clarifying word makes the results strictly worse.<\/p>\n\n\n\nmaggi's noodles<\/code> still served me an ad. For Yippee, a competing noodle brand. The ads engine understood and monetized the exact query the search engine claimed does not exist, on the same page, in the same request.<\/p>\n\n\n\nTheir own blog says this should be impossible<\/h2>\n\n\n\n
\n
Why the guest path is the one that matters<\/h2>\n\n\n\n
\n
The four fundamentals the guest path is missing<\/h2>\n\n\n\n
1. Fuzzy matching: a config flag, not a project<\/h3>\n\n\n\n
\"fuzziness\": \"AUTO\"<\/code> on a match query and terms match within one or two character edits. maggis<\/code> matches maggi<\/code>. That is the entire fix for two of the three guest failures.<\/p>\n\n\n\nmaggis<\/code>, the exact case edit-distance handles in microseconds. The hard 5% got an 8-billion-parameter model; the easy 80% did not get the one-line config.<\/p>\n\n\n\n2. A relaxation ladder: never show a blank page<\/h3>\n\n\n\n
dudh of mother dairy<\/code> relaxes to mother dairy<\/code>, which returns a full brand page at my store. The user never sees the retries. They just see milk.<\/p>\n\n\n\n3. Semantic fallback: the net exists, but not here<\/h3>\n\n\n\n
maggis noodles<\/code> and maggi noodles<\/code> are practically the same point in any embedding space. If semantic recall backstopped empty lexical results, a blank guest page would be nearly impossible. Three blank pages later, it evidently does not run on this path.<\/p>\n\n\n\n4. One guardrail: smart search must never lose to dumb search<\/h3>\n\n\n\n
LIKE '%maggi%'<\/code> finds Maggi products for every one of my five queries. The guest pipeline failed three of them. When the clever path returns empty, fall back to the dumb path. It is one comparison at the end of the pipeline, and it would have made every failure in this post invisible.<\/p>\n\n\n\nBonus: the caching claim does not hold either<\/h2>\n\n\n\n
The lesson<\/h2>\n\n\n\n