System design interview guide
Blinkit System Design: 10-Minute Delivery at Scale
From April to June 2026, Blinkit ran 2,443 dark stores. A year earlier it had 1,544. It served 31.8 million customers a month. It worked with about 521,000 delivery partners a month. Each store sold about ₹8.27 lakh a day. The average order was ₹518. So each store handled about 1,600 orders a day. Across all stores, that is about 3.9 million orders a day. These two order numbers are my own estimates from Eternal's figures. Blinkit also reported stock losses of 1.8% of its order value. That was about ₹308 crore in the quarter. It is stock the system thought it had, but did not.
Blinkit delivers groceries and daily items in about 10 minutes. It keeps stock in small warehouses near customers. These are called dark stores. Every customer is really shopping one nearby store's shelves. So the core of the design is knowing exactly what each store has, at all times. You also need to pick which store serves an address. You need to hold an item for a customer while they pay. You need to pick and pack fast, and send a delivery partner. Blinkit's own numbers add three harder problems. First, it opened about 900 stores in one year. So opening a store must be a data change, not a code change. Second, stock goes missing, about 1.8% of order value in one quarter. So the system must expect its records to be wrong, and catch it. Third, in September 2025 Blinkit started owning its stock. Before, sellers owned it. This changed the meaning of every stock record while the stores kept selling.
Where it shows up
A natural question for quick-commerce and retail roles in India. Think of Blinkit, Zepto, Swiggy Instamart, Flipkart Minutes and BigBasket. It also suits any team that runs stock, warehouses or last-mile delivery. The general forms are simple. Design a 10-minute grocery app. Design real-time stock for many small warehouses. Design order routing to the nearest store.
Why this question is asked
It looks like a normal e-commerce question. That is the trap. With 2,443 small stores, stock is not one number per product. It is one number per product, per store. And the customer can only buy what their one store has. So you must talk about what interviewers care about. Keep a count correct when many people buy the last item at once. Hold stock for a buyer without locking it forever. Admit that the record and the shelf sometimes disagree, and design for it. And serve millions of 'is it in stock' reads without overloading the main database.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Map a customer's address to the one dark store that serves it
- Show only products that store has in stock now, with the right price
- Customers search, build a cart and pay by UPI, card or wallet
- Hold items for the customer while they pay, and release them if payment fails
- Send the order to the store, pick and pack it, and hand it to a delivery partner
- Show live order tracking to the customer
- Refill stores from larger warehouses, based on expected demand
- Let store staff report missing or damaged stock, and fix the counts
Non-functional requirements
- Never sell an item the store does not have, even when many buy the last one at once
- Deliver in about 10 minutes, so every step has a tight time limit
- Answer 'what is in stock here' very fast, because people browse much more than they buy
- Handle about 4 million orders a day, with big evening, weekend and festival peaks
- Opening a new store takes days of setup, not engineering work
- Check the stock record against the real shelf often, and find differences fast
- A problem in one store, like a broken scanner, must not affect other stores
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Dark stores
2,443 (Q1 FY27)
Eternal reported 2,443 Blinkit stores at the end of June 2026. It added 200 in that quarter. A year earlier it had 1,544. That is about 900 new stores in twelve months, more than two a day.
Orders per store per day
~1,600
Eternal reported ₹8.27 lakh of orders per store per day. The average order was ₹518. ₹8,27,000 divided by ₹518 is about 1,600 orders a day. That is more than one order a minute, all day and night. The evening peak is much busier. This is my calculation from the reported numbers. Blinkit did not publish it.
Orders per day, all stores
~3.9 million (estimate)
About 1,600 orders a day, times 2,443 stores, gives about 3.9 million orders a day. It is an estimate from averages. New stores sell less than old ones. So treat it as the right size, not an exact count.
Monthly customers
31.8 million
This is the average number of monthly buying customers in the quarter. A year earlier it was 16.9 million, so it nearly doubled. Browsing traffic is many times higher than orders. People open the app just to check prices and stock.
Delivery partners
~521,000 a month
This is the average number of monthly delivery partners in the quarter. A year earlier it was 243,000. The system must match these riders to orders, store by store, in minutes.
Stock losses
1.8% of order value
Blinkit reported stock losses of 1.8% of its order value in the quarter, about ₹308 crore. Losses mean stock that was expected but was not there. Causes include damage, expiry, theft and counting errors. At this size, a small error is a lot of money.
High-level architecture
Design Blinkit around one idea. Every customer is shopping one store's shelves. So the store is the unit of almost everything. Split the system into three layers. The customer layer covers the app, search, cart and payment. It must answer 'what can I buy here' very fast. The store layer owns the truth for each store. It knows what is on the shelf, what is held for customers, and what is being picked. The delivery layer moves stock into stores from warehouses. It also moves orders out to customers with delivery partners. The key choice is to split the stock data by store. Each store's stock lives together. So a rush of orders in one area touches one store's data only. The other 2,442 stores are not affected. The store's stock service is the only thing allowed to change a count. It records every change as an event: stock received, item held, hold released, item picked, item reported missing. The fast 'in stock' view in the app is built from those events. It can be a second or two behind. The hold at checkout is what keeps things correct. Around this sit a few more parts. Order routing picks the store for an address. Picking and packing happen inside the store. Dispatch sends a delivery partner. Refilling forecasts demand per product, per store, and sends stock from larger warehouses.
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.
Store routing
It maps a customer's location to the one store that serves it. Each store has a delivery area drawn on a map, not a simple circle. A road or a river can make a nearby store slow to reach. The areas are data. So they can be redrawn when a new store opens nearby, without new code.
Catalog and prices
The list of products and their prices. The main catalog is shared by all stores. But each customer sees only the products their store stocks. It is read far more than it is changed, so it is kept in a fast cache.
Store stock service (the truth)
For every store, it holds the count of each product on the shelf. It also holds the count held for open orders. It is the only thing that changes stock. Every change is recorded as an event. So later you can find out why the record and the shelf disagree.
Fast stock view for the app
A fast, read-only copy of 'what is in stock at this store'. It is built from the stock events and kept in memory. Millions of browsing requests read this copy, not the truth. It can be a moment behind. That is fine, because the hold at checkout is the real check.
Cart, hold and payment
At checkout, the items are held in the store's stock for a few minutes while the customer pays. If payment works, the hold becomes an order. If payment fails or takes too long, the hold ends. The stock goes back on sale.
Picking and packing in the store
It turns an order into a pick list, sorted by where items sit in that store. So a picker walks the shortest path. Scanning each item is also a stock check. If the scanner cannot find an item the record says is there, that is a sign of loss.
Dispatch
It assigns a delivery partner who is at or near the store. The goal is for them to arrive just as the bag is packed. Stores are close to customers, so the ride is short. Most of the time goes into picking and waiting for a partner. So timing matters more than the route.
Refilling and forecasting
It predicts demand for each product in each store. Then it sends stock from larger warehouses before it runs out. A small store can hold only a few thousand products. Choosing what to stock, and how much, decides whether the app shows 'out of stock'.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
storesstore_id (PK)geoservice_area (polygon)statusopened_atOne row per dark store. The delivery area is stored as a shape on a map, and it can be redrawn. Opening a store means adding rows here and in the catalog. So 900 stores in a year is work for operations, not for engineers.
store_stockstore_idsku_idon_handreservedversionupdated_atThe truth for each product in each store, split by store_id. Stock you can sell is on_hand minus reserved. The version number lets the service reject an update based on an old count.
stock_eventsevent_id (PK)store_idsku_idtype (received, reserved, released, picked, lost, adjusted)qtyref_idatEvery change to stock. Rows are only added, never edited. The current count is the sum of these events. The fast view in the app is built from them. When the shelf and the record disagree, this is where you find out when it started.
reservationsreservation_id (PK)store_idcart_iditemsexpires_atstateA hold on stock for one checkout, with a time limit. A background job ends old holds. So a customer who closes the app does not block stock for everyone else.
ordersorder_id (PK)customer_idstore_iditemsamount_paisepayment_idstatecreated_atThe confirmed order. It is made only after payment works, against a live hold. Amounts are whole paise.
stock_ownershipstore_idsku_idowner (seller_id or blinkit)cost_pricegrn_refsinceWho legally owns the stock, and at what cost. Under the old model, the owner was a seller. Since 1 September 2025, it is Blinkit's own company. Ownership is kept apart from the count. That is why the change did not touch picking or selling.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Selling the last item exactly once
The hardest problem is the last unit. Three customers near one store all add the last packet of milk. They all check out at the same moment. Say each one reads 'one left' and then writes 'zero left'. Then all three orders succeed. Two customers get a cancelled order ten minutes later. The fix is to make the check and the change one step. Hold the item only if enough stock is left, in one update. Only one of the three succeeds. The other two are told right away that it just sold out. Stock is split by store, so this contest happens inside one store's data only. It stays small and fast, even at millions of orders a day.
UPDATE store_stock
SET reserved = reserved + $3, version = version + 1
WHERE store_id = $1 AND sku_id = $2
AND on_hand - reserved >= $3
RETURNING version; -- no row returned: sold out, tell the customer now
Two kinds of 'in stock': the fast view and the truth
31.8 million monthly customers browse far more than they buy. Every product tile asks 'is this in stock at my store?'. If every one of those reads hit the truth, reads would crowd out the writes that matter. So there are two views. The truth lives in the store stock service. Only writes and checkout touch it. The fast view is a copy built from the stock events. It lives in memory and can be a second or two behind. Now and then it shows an item that just sold out. The hold at checkout catches that before the customer pays. This is a common trade. Make reads fast and a little out of date. Put the real check at the one moment that needs it.
Design for a record that is wrong
Blinkit reported stock losses of 1.8% of its order value in one quarter. That is about ₹308 crore. This is the real world disagreeing with the database. Items get damaged, expire, get stolen or are counted wrong. A design that trusts the count completely fails here. The app keeps selling an item that is not on the shelf. Then the order fails at picking. So the system treats every physical touch as a check. A picker scans the shelf, and the item is not there. The stock service records a 'lost' event. The item stops selling at that store at once. Staff also count a few shelves each day to fix the rest. Every change is an event. So the business can see where losses come from, by product and by store. It does not have to wait for the quarter's total.
Opening two stores a day
Blinkit went from 1,544 to 2,443 stores in a year. That is about 900 new stores. It added 200 in one quarter alone. If each new store needed an engineer, this pace would be impossible. So a store must be pure data. It is a row in the stores table and a delivery area drawn on a map. Add a starting catalog and a first load of stock, and it is ready. The routing, stock, picking and dispatch services all read the store list. They work for any store without changes. Splitting stock by store helps here too. A new store gets its own data, so it cannot slow down the old ones. Sometimes a new store opens next to an old one. Then the old store's delivery area is redrawn, and customers move over. That is also just a data change.
Changing who owns the stock while stores keep selling
Until August 2025, Blinkit ran as a marketplace. Sellers owned the stock in the dark stores. Blinkit was the platform. Then its parent company, Eternal, became Indian-owned and controlled. Under India's investment rules, that let Blinkit own stock. From 1 September 2025, Blinkit buys from brands and sellers and sells to customers itself. Sellers had until 30 July to agree. Stock moved to Blinkit's company, valued at cost or through a goods received note. For the system, this was a data move while stores kept running. Every unit on every shelf changed its legal owner and its cost. The design that makes this safe is simple. Keep ownership and cost in their own record, apart from the physical count. Picking, holds and the app only care how many units are on the shelf. Accounting and tax care who owns them. Because they were separate, ownership could change without customers noticing.
The ten-minute budget
Ten minutes must cover everything. The order reaches the store. A picker packs it. A delivery partner arrives. Then the ride. Stores are close to customers, so the ride is only a few minutes. Most of the time is spent inside the store. That is why the pick list is sorted by where items sit. It is why picking starts the moment payment works, not in batches. And it is why dispatch tries to have a partner at the door just as the bag is sealed. The lesson is to find where the time really goes. Here it is picking and waiting, not driving. So that is where the engineering goes.
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.
Split stock by store versus one big stock table
One big table is easier to query across stores. But every order everywhere would compete for the same data. Splitting by store means a rush in one area only touches that store's data. A new store is just new data. The cost is that network-wide questions need a separate reporting system. Total stock of one product is an example.
A fast, slightly old view versus reading the truth every time
Reading the true count for every product tile would be exact. But it would flood the stock service with reads. A copy that is a second or two behind is cheap to serve in huge volume. The cost is a rare 'just sold out' at checkout. The hold catches it before the customer pays.
Holds with a time limit versus holding only after payment
Holding only after payment keeps stock on sale longer. But then a customer can pay and still lose the item to someone faster. Holding at checkout, with a short time limit, means a paying customer always gets the item. The cost is that stock is briefly held for people who leave. The time limit releases it.
Owning the stock versus running a marketplace
A marketplace does not hold stock or its losses. The sellers carry that risk. Owning stock gives control over range, price and availability. It became allowed once Eternal was Indian-owned and controlled. The cost is that losses like the 1.8% are now Blinkit's own money. So accurate stock tracking directly affects profit.
Many small stores versus a few large warehouses
A few large warehouses cost less per unit and are easier to run. But they are too far from customers for a ten-minute promise. Many small stores make the promise possible. The cost is thousands of separate stock lists. Each store is small, so choosing what to stock in each one decides whether customers find what they want.
How Blinkit actually does it
Blinkit's numbers here come from Eternal's results for April to June 2026, as reported by MediaNama. The move to owning its stock comes from reports on Blinkit's July 2025 notice to sellers. Blinkit has not published how its systems are built. So the design on this page fits those public numbers. It is not a description of Blinkit's code. The orders-per-day numbers are my own estimates from the reported averages. For a company that has shared details of its systems, see the Zepto page. It covers the dark-store model through its published databases.
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.
Geospatial Indexing
intermediate / database types storage
Database Sharding
foundation / database fundamentals
Event Sourcing
advanced / distributed systems core
Cache-Aside Pattern
foundation / caching strategies
Message Queues
intermediate / messaging event systems
Idempotency Keys
intermediate / api design protocols
High Availability
advanced / reliability resilience
Related system design interview questions
Practice these next. They lean on the same core building blocks as Blinkit.