Meesho System Design Interview: Discovery Commerce at Scale
More than three-quarters of Meesho's orders come from an AI discovery feed, not from search, because its shoppers, roughly half of them from small towns, browse rather than type. Meesho reported over 100 ranking models making trillions of inferences a day, serving about 234 million annual shoppers who placed more than 1.3 billion orders in a year.
Designing Meesho is an e-commerce problem with a different shape from the usual one. Its users are largely first-time online shoppers in tier-2, tier-3, and smaller towns who browse a personalized feed in their own language rather than searching for a product by name, so the home screen is a recommendation problem, not a search box. The baskets are small and the order volume is enormous, which makes cost per order the number that decides whether the business works, so the engineering is obsessed with efficiency. This walkthrough centers on the discovery feed and the machine-learning platform behind it, both of which Meesho has published, on the low-cost-per-order economics, and is honest about which parts of the order path are the standard e-commerce pattern.
Asked at: Commonly asked at Meesho, Flipkart, Amazon, and consumer-internet and e-commerce teams, and the general forms, meaning design an e-commerce app, a recommendation feed, or a personalization system, show up at most product companies for SDE2 and SDE3 rounds. Meesho is a good question because it reframes e-commerce around discovery and recommendation rather than search and catalog, and around cost efficiency at very high, low-value order volume.
Why this question is asked
Most e-commerce interview answers start with a search box and a catalog. Meesho breaks that assumption, because its users mostly do not search, they scroll a feed, so the core problem becomes ranking the right products for each user in real time. That turns the design into a large-scale machine-learning serving problem: candidate generation, feature lookups, and ranking models on the hot path, in many languages, for hundreds of millions of users. On top of that, Meesho's baskets are small, so the design has to keep the cost per order extremely low, which forces real conversations about caching, infrastructure efficiency, and even owning logistics. Interviewers use Meesho to check whether you can design a recommendation feed as a system, reason about a feature store and low-latency model serving, and treat cost per order as a first-class constraint, not just throughput and latency.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- A user opens the app to a personalized home feed of products, ranked for them, without needing to search
- The feed works in the user's language, and for shoppers who browse rather than type
- Search and category browsing exist as a secondary path for users who do want to look something up
- User views a product, adds to cart, and places an order, paying by UPI, card, or cash on delivery
- Sellers list products at zero listing commission, and the platform ranks and surfaces those listings
- The system records every interaction (view, click, add to cart, wishlist, order) to improve future ranking
- Order tracking and delivery, including through Meesho's own logistics network
- Absorb large traffic surges during sale events
Non-functional requirements
- Rank and serve the personalized feed in real time for hundreds of millions of users, with low latency on the home screen
- Keep cost per order very low, because baskets are small and order volume is enormous
- Support 10-plus Indian languages in ranking and discovery
- Absorb sale-event spikes of roughly 10x normal load, and larger surges within hours
- High availability on the feed and order paths, since the feed is how most orders start
- Capture and serve fresh interaction signals quickly, so the feed reacts to what a user just did
- Scale the machine-learning serving to trillions of inferences a day, with peaks around 100 million inferences a second
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Annual transacting users
~234M (TTM Sep 2025)
Meesho reported about 234 million annual transacting users for the twelve months to September 2025, up from about 175 million a year earlier. This is the base the feed must personalize for.
Orders
1.3B+ in 2024
Meesho reported more than 1.3 billion orders in 2024, growing about 35 percent year on year, with over half placed by small-town buyers. The enormous order count at small basket sizes is what makes cost per order the key metric.
Gross merchandise value
~70,160 crore rupees (TTM Sep 2025)
Meesho reported gross merchandise value of about 70,160 crore rupees for the twelve months to September 2025. Large total value spread across very many low-value orders.
Discovery feed share
>75% of orders from the AI feed
Meesho reported that more than 75 percent of orders come from its AI-powered discovery feed rather than search. This is why the feed, not the search box, is the center of the design.
ML serving scale
6T inferences/day, ~100M/sec peak
Meesho reported its ranking stack runs over 100 models making around 6 trillion inferences a day, peaking near 100 million inferences a second during sale events. This sizes the machine-learning serving layer.
Sellers and tier-3 reach
~706K sellers, ~50% users tier-4+
Meesho reported about 706,000 annual transacting sellers, and roughly half its users come from tier-4 and smaller towns. The seller base drives catalog and ranking, and the tier-3 focus drives the vernacular, browse-first design.
High-level architecture
Design Meesho around the discovery feed, because that is where most orders start and it is the part Meesho has published in detail. The order and payment path is the standard e-commerce pattern and is described as such. The home screen is a ranking problem, not a search query. When a user opens the app, the system has to assemble a personalized feed of products for them in real time. Meesho described this as a two-part job. First, candidate generation pulls a manageable set of products from the huge catalog through several channels at once: products the user is likely to buy based on history, exploratory products to learn their taste, popular products, and recent additions. Second, a ranking layer scores those candidates for this user, predicting the probability of a click and the probability of a purchase, and orders the feed by them. Meesho reported that this discovery engine runs more than 100 ranking models and drives over 75 percent of orders, serving 10-plus languages so that a shopper who does not type in English still gets a relevant feed. Under the feed sits a machine-learning platform, which Meesho open-sourced as BharatMLStack. It has two stores that matter. A feature store holds the signals the models need, built on Cassandra for durable storage and Redis for low-latency serving, with a gRPC and Protocol Buffers layer for fast communication and schema information kept in ZooKeeper. An interaction store keeps each user's most recent actions, clicks, orders, add-to-carts, wishlists, using Redis sorted sets so the last-k interactions are cheap to read and always time-ordered, which is what lets the feed react quickly to what a user just did. A config-driven execution framework runs the steps of a request as a graph, in parallel with retries, so a feed request fans out to candidate sources and feature lookups efficiently. The order and payment path is the familiar e-commerce shape and is not something Meesho has published in detail: a cart, a checkout that captures payment idempotently, an order service with a state machine, and fulfillment. What is distinctive is the economics. Because baskets are small and volume is huge, cost per order is the metric that matters, so the infrastructure is tuned hard for efficiency. Meesho reported large cost reductions from using Redis for messaging, caching, rate limiting, and queues, cutting one live-commerce messaging bill by around 90 percent and server costs by around 65 percent over two years, and it built its own logistics network, Valmo, to compress the shipping cost of low-value orders. Meesho runs across more than one cloud rather than a single provider.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Discovery feed and candidate generation
The home-screen engine that assembles a personalized product feed in real time. It generates candidates from several channels at once, products the user is likely to buy, exploratory ones, popular ones, and recent additions, then hands them to ranking. Meesho reported this feed drives more than 75 percent of orders.
Ranking models
The layer that scores candidate products for a specific user, predicting the probability of a click and of a purchase, and orders the feed by them. Meesho reported running over 100 ranking models across its discovery engine, making trillions of inferences a day, in 10-plus languages.
Feature store (BharatMLStack)
The store of signals the ranking models read, from Meesho's open-sourced ML platform. It uses Cassandra for durable storage and Redis for low-latency serving, communicates over gRPC and Protocol Buffers, and keeps feature schema information in ZooKeeper. It is what lets models get their inputs fast enough to rank a feed on the hot path.
Interaction store
The record of each user's most recent actions, clicks, orders, add-to-carts, wishlists, and shares. Meesho built it on Redis sorted sets so the last-k interactions per user are cheap to read and always time-ordered. This is the freshest signal, and it lets the feed react within moments to what a user just did.
Model serving and execution framework
The layer that runs a feed request as a graph of steps, candidate sourcing, feature lookups, and model scoring, in parallel with retries, and serves the models at scale. Meesho reported peaks near 100 million inferences a second during sale events, with auto-scaling inference endpoints handling the surge.
Catalog and search
The product catalog and the secondary search and category-browse path for users who do want to look something up. Read-heavy and cached. It is secondary to the feed for Meesho, the reverse of a search-first marketplace.
Order, cart, and payment services
The standard e-commerce write path: cart, a checkout that captures payment idempotently across UPI, card, and cash on delivery, and an order service with a state machine. Meesho has not published these internals, so they are described as the general pattern rather than a Meesho-specific design.
Logistics network (Valmo)
Meesho's own logistics marketplace, built to carry a large share of daily orders and compress the shipping cost of small, low-value shipments. Owning logistics is part of how Meesho keeps cost per order low enough for its economics to work.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
usersuser_id (PK)languagelocation_tiercreated_atstatusThe shopper, with language and location tier that feed personalization. Roughly half of users are from tier-4 and smaller towns, and language drives the vernacular feed.
productsproduct_id (PK)seller_idcategoryprice_paiseattributes (jsonb)ratingThe catalog listing. Read-heavy and cached. Products are the candidates the feed ranks. Prices are typically low, which shapes the whole cost model.
sellersseller_id (PK)namestatuslisting_commissionThe supplier, listed at zero listing commission. Meesho reported about 706,000 annual transacting sellers. Monetization comes from ads and logistics rather than a listing cut.
interactionsuser_idproduct_idtype (view|click|atc|wishlist|order)tsThe signal stream. Stored in Redis sorted sets keyed by user so the last-k interactions are time-ordered and cheap to read. The freshest input to ranking, so the feed reacts to recent behavior.
featuresentity_id (PK)entity_type (user|product|seller)feature_valuesupdated_atThe feature store, on Cassandra for durability and Redis for serving. Holds the precomputed and real-time features the ranking models read on the hot path, served over gRPC.
ordersorder_id (PK)user_iditems (jsonb)amount_paisepayment_idstatecreated_atThe transactional order record. Small basket values, enormous count. Standard e-commerce order state machine. Strong consistency on the money and the order state.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Why the feed, not search, is the core problem
Meesho's thesis is that its next hundred million shoppers will not search, they will discover, because many are first-time online buyers in smaller towns who browse a feed rather than typing a product name, often in a language other than English. That single fact reshapes the system. In a search-first marketplace, the hard problem is matching a query to a catalog. For Meesho, the home screen has to decide, with no query at all, what to show each user, which is a ranking problem run for every user on every open. Meesho reported that more than 75 percent of orders come from this AI discovery feed, so the feed is not a nice-to-have, it is the primary storefront. The design consequence is that machine-learning serving, candidate generation, feature lookups, and ranking, sits on the most trafficked hot path in the product, and everything about latency, cost, and freshness is judged there first.
Candidate generation and ranking
Ranking every product in a huge catalog for every user on every open is impossible, so the feed works in two stages. First, candidate generation narrows the catalog to a manageable set through several channels at once: an exploit channel of products the user is likely to buy from their history, an explore channel of products that help learn their taste, a popularity channel, and a recent channel. Pulling from multiple channels keeps the feed both relevant and fresh, and avoids the trap of only ever showing more of what a user already clicked. Second, a ranking model scores those candidates for this specific user, predicting the probability of a click and the probability of a purchase, and the feed is ordered by a combination of the two. Meesho reported building this on managed cloud machine-learning infrastructure with auto-scaling inference, and getting a measurable conversion lift from the approach. The interview point is the funnel: cheap, broad candidate generation first, then expensive, precise ranking on a small set.
The machine-learning platform: feature store and interaction store
A feed request has to gather many signals about the user and the candidate products and run them through models, all within the latency budget of a home-screen load, which is why Meesho built a dedicated ML platform, open-sourced as BharatMLStack. Two pieces are worth describing. The feature store holds the model inputs, using Cassandra for durable storage and Redis for low-latency serving, with a gRPC and Protocol Buffers layer for fast, compact communication and feature schema kept in ZooKeeper; Meesho even worked around a practical column limit in Cassandra by grouping features. The interaction store keeps each user's most recent actions in Redis sorted sets, so the last-k clicks, orders, and add-to-carts are time-ordered and cheap to read. That freshness matters: because the newest interactions are instantly available, the feed can react to what a user did seconds ago, not just to yesterday's batch-computed features. Separating a fast interaction store from the broader feature store is a clean way to serve both slow, rich features and fresh, recent signals.
Serving trillions of inferences and surviving sale spikes
Running over 100 models for hundreds of millions of users adds up to enormous serving volume, which Meesho put at around 6 trillion inferences a day and near 100 million inferences a second at sale-event peaks. Two things make that survivable. First, the model serving auto-scales, so inference capacity grows for a sale and shrinks afterward rather than being provisioned for the peak all the time. Second, aggressive caching and a fast interaction and feature layer keep each inference cheap and keep repeated work off the models. Meesho also reported absorbing surges of roughly 10x normal load during sales and up to 20x within hours, leaning on Redis for caching, rate limiting, queues, and real-time messaging. The lesson is that a recommendation-driven product has to treat its ML serving tier as a first-class, elastically scaled system, not as an add-on to a web backend.
Designing for cost per order, not just throughput
Meesho's economics are unusual: baskets are small and order volume is huge, so the cost of serving and shipping each order, rather than raw throughput or latency, is what decides whether the business works. This shows up throughout the engineering. Meesho reported cutting a live-commerce messaging bill by around 90 percent and server costs by around 65 percent over two years by using Redis well for caching, rate limiting, queues, and messaging, and it built its own logistics network, Valmo, to compress the shipping cost of low-value packages. Even the zero-commission model for sellers is a design constraint, since Meesho makes money from ads and logistics rather than a listing cut, which puts more weight on the recommendation feed that surfaces the right products and the ads within it. In an interview, treating cost per order as a primary design metric, and showing where caching, elastic scaling, and owned logistics reduce it, is what separates a Meesho answer from a generic high-traffic one.
Vernacular, browse-first design for the next hundred million users
Meesho is built for shoppers who are often new to online buying, may not read English comfortably, and prefer to browse rather than search. That is a system requirement, not just a UX choice. The ranking and discovery stack supports 10-plus Indian languages, so relevance is computed for a user in their own language. The reliance on a feed instead of a search box means the system cannot lean on a user typing a precise query to express intent; it has to infer intent from behavior, which puts even more weight on the interaction signals and the ranking models. And it means visual and browse-friendly presentation matters, since the feed is doing the work a search query would otherwise do. Designing for this user is why the recommendation feed, the multi-language models, and the fresh interaction store are central rather than peripheral.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
A discovery feed versus a search-first storefront
A search-first design is simpler and works well when users know what they want and can type it. Meesho's users largely browse rather than search, often in a non-English language, so a feed that infers intent from behavior converts far better for them, and Meesho reported over 75 percent of orders coming from it. The cost is that the feed is a large, always-on machine-learning system on the hottest path, which is far more complex and expensive to build and serve than a search index, accepted because it matches how the users actually shop.
Building a dedicated ML platform versus stitching together off-the-shelf tools
Using managed services piecemeal is faster to start, but at Meesho's serving volume the latency, cost, and consistency of feature access become the bottleneck. Building a dedicated platform, with a purpose-built feature store on Cassandra and Redis and a fast interaction store, gives control over hot-path latency and cost. The cost is the engineering to build and run the platform, accepted because feed relevance and its cost directly drive the business, and Meesho open-sourced the result.
A separate fast interaction store versus one feature store for everything
Keeping all signals in one feature store is simpler, but the most recent interactions need to be both extremely fresh and extremely cheap to read, which a general store optimized for rich features does not do as well. Meesho used Redis sorted sets for a dedicated interaction store so last-k actions are time-ordered and instant, alongside the broader feature store. The cost is two systems to maintain, accepted because feed freshness depends on serving recent behavior with almost no delay.
Zero listing commission plus ads and logistics revenue versus a marketplace cut
Charging sellers a listing commission is the standard marketplace model and simplest to reason about. Meesho charges zero listing commission and monetizes through ads and logistics instead, which attracts a very large seller base but shifts the revenue burden onto the recommendation feed and its ads. The cost is that the feed must be excellent, since it is both the storefront and the ad surface, which is one more reason the ranking system gets so much investment.
Owning logistics (Valmo) versus using third-party couriers
Using third-party couriers is less work and avoids building a logistics business. But for very low-value orders, shipping cost is a large fraction of the order and third-party rates can make the economics fail. Meesho built its own logistics network to compress that cost across a huge order volume. The cost is running a logistics operation, accepted because cost per order is the metric that decides the business and shipping is a big part of it.
Elastic ML serving versus provisioning for peak
Running enough inference capacity for the sale-event peak all year is simplest but very expensive for a cost-sensitive business. Auto-scaling the model serving up for sales and down afterward matches capacity to demand, which Meesho reported doing along with absorbing 10x to 20x surges. The cost is the complexity of elastic scaling and keeping latency stable as capacity changes, accepted because paying for the peak continuously would break the cost-per-order math.
How Meesho actually does it
The discovery feed and the machine-learning platform are documented by Meesho, on its engineering blog, in an AWS co-authored case study, and through its open-sourced ML platform, while the order and payment internals are not published and are described as the standard e-commerce pattern. Meesho reported that more than 75 percent of orders come from its AI discovery engine, which it said runs over 100 ranking models making around 6 trillion inferences a day, peaking near 100 million inferences a second during sales, across 10-plus Indian languages. Its published feed ranker generates candidates from several channels and ranks them by predicted click and purchase probability, built on managed cloud machine-learning inference with a reported conversion lift. Meesho open-sourced its ML platform, BharatMLStack, whose feature store uses Cassandra and Redis with a gRPC and Protocol Buffers layer and schema in ZooKeeper, and whose interaction store uses Redis sorted sets for last-k user actions. Meesho reported large efficiency gains from Redis, including cutting a live-commerce messaging cost by around 90 percent and server costs by around 65 percent over two years, and absorbing roughly 10x to 20x load surges during sales. On scale, Meesho reported about 234 million annual transacting users for the twelve months to September 2025, more than 1.3 billion orders in 2024, gross merchandise value of about 70,160 crore rupees, and about 706,000 annual transacting sellers, with roughly half its users from tier-4 and smaller towns. It lists sellers at zero listing commission and monetizes through ads and logistics, and built its own logistics network, Valmo. Three accuracy notes for the interview. First, Meesho's user, order, and value figures shift by reporting period, so pin the date. Second, Meesho has not published a total catalog or SKU count, and specific order-pipeline internals are not public, so do not present those as Meesho facts. Third, Meesho runs across more than one cloud rather than a single provider, and it has not named an event-streaming system like Kafka publicly, so treat an event bus as the general pattern.
Sources
- AWS Machine Learning Blog, How Meesho built a generalized feed ranker using Amazon SageMaker inference: candidate channels, click and purchase prediction, auto-scaling serving
- Meesho Tech, Building Meesho's ML platform (BharatMLStack): the feature store on Cassandra and Redis, gRPC and Protocol Buffers, and the Redis sorted-set interaction store
- Redis, Meesho customer case study: Redis for messaging, caching, rate limiting and queues, with about 90 percent messaging and 65 percent server cost reductions and 10x to 20x spike absorption
- Storyboard18, Meesho says over 75 percent of orders come from its AI discovery engine PRISM: 100-plus models and trillions of inferences
- Business Standard, Meesho order growth 35 percent in 2024 driven by small towns: orders, tier-4 reach, and sellers
- Meesho Tech, Launching infrastructure as code through Terraform: Meesho's infrastructure and DevOps practice
- Medianama, Meesho files IPO draft with SEBI: user, gross merchandise value, and seller figures from the filing
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Cache-Aside Pattern
foundation / caching strategies
Cache Stampede Prevention
foundation / caching strategies
Message Queues
intermediate / messaging event systems
Database Sharding
foundation / database fundamentals
Load Balancing
foundation / core fundamentals
Rate Limiting for Resilience
advanced / reliability resilience
High Availability
advanced / reliability resilience