System design interview guide
Myntra System Design: Fashion E-Commerce and the End of Reason Sale
Short answer
Myntra system design splits browsing from buying. Browsing is huge, so it reads caches, a search index and a price book. Sale prices are loaded days early with a start time, so nothing is written at the sale minute. Buying is exact. Stock is kept per size, per warehouse or store, and checkout holds one unit with one conditional update. An order service picks where to ship from. Returns are a full flow: pickup, check, refund once, then restock. In 2016 Myntra peaked at 7,000 orders a minute, and in 2021 it said it was ready for 15,000.
Asked about a general e-commerce flash sale instead? See the Flipkart Big Billion Days guide
Two courses by the author of this page:
770 lessons · 18 free to read
₹1,111 in India · $25 elsewhere, once
Get System DesignYou own this course
214 lessons · 10 free to read
₹1,333 in India · $35 elsewhere, once
Get Generative AI and Agentic AIYou own this course
Save your progress and get the interview checklist PDF
In its July 2016 sale, Myntra took three million orders in two days. At the peak it took 7,000 orders a minute. That peak was 6.7 times the sale's own average. By December 2021 it said its platform was ready for 15,000 orders a minute at peak. That is 250 orders every second. And every order is for a style in one size. So the shop is really millions of small stock counts.
Myntra sells fashion online in India. Flipkart bought it in May 2014. Its big event is the End of Reason Sale, which runs twice a year. Fashion changes the usual shop design in four ways. First, stock is per size. A shirt in six sizes is six separate counts, and the popular sizes run out first. Second, prices change at a fixed minute when the sale starts. Millions of people are waiting for that minute. Third, stock sits in warehouses and in brand stores, so each order must pick where to ship from. Fourth, many fashion items come back. So returns are a normal path, with pickup, a check, a refund and a restock.
Where it shows up
A natural question for e-commerce roles in India. Think of Myntra, Flipkart, Ajio, Nykaa Fashion and Meesho. Searches like "myntra interview questions" and "myntra sde interview experience" show how many people prepare for it. The general forms are: design a fashion shop, design a flash sale, and design returns for e-commerce.
Spec sheetMyntra
- 01Sale peak versus sale average (2016)
- 6.7x
- 02Orders per second at the 2021 target
- 250
- 03Stock holds per second
- ~750
- 04Product page reads per second
- ~12,500
worked through below, with the maths
Why this question is asked
It sounds like the Flipkart question, but fashion makes it harder in specific ways. A sale starts at one minute, so the load arrives as a wall, not a curve. Stock is split by size, so one style can be sold out in M and full in XL. Prices must change for millions of items at the same instant. And returns are common, so the design must handle money and stock going backwards. A strong answer names each of these and fixes it with a simple tool.
This page is the free part.
The course goes deeper on the Myntra design
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers the Myntra design across a run of lessons, not one page. These 4 alone are about 105 minutes of step-by-step reading, every one with a quiz.
- Cache Warming
A cold instance in a warm fleet served its users at 8.14 ms while their neighbours got 3.69, and the fleet average moved by 0.68 ms. The largest fix was not a warming job.
- Cache Stampede Prevention
Two problems share the name. Single flight took 306,687 loads down to 81,233 and did nothing to the spike. TTL jitter took the peak second from 506 to 339 and removed no work at all.
- Load Shedding
Deliberately reject excess traffic to protect core functionality, prioritize important requests.
- Database Sharding
Splitting a database across multiple servers, the nuclear option for scaling writes, and the architecture behind Instagram, Uber, and YouTube.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Cache Warmingpay once,
yours for life
Live from the course bench
Before you design Myntra, try the questions it rests on.
Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Browse and search styles, with filters for size, brand, price and colour
- Show stock for each size, and hide sizes that are sold out
- Switch to sale prices at the exact minute the sale starts
- Build a cart, check out and pay by UPI, card or cash on delivery
- Hold stock for a size while the customer pays
- Pick the warehouse or store to ship from, and track the parcel
- Book a return pickup, check the item, refund the customer and restock
- Suggest a size, based on the customer's past buys and returns
Non-functional requirements
- Take about 250 orders a second at the sale peak, by the 2021 target
- Serve product pages very fast, because people browse far more than they buy
- Never sell a size that is not in stock
- Every customer sees the same sale price from the same second
- A slow part, like size suggestions, must not block checkout
- Refunds must never be paid twice
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Sale peak versus sale average (2016)
6.7x
Myntra took three million orders over two days in July 2016. Two days is 2,880 minutes. 3,000,000 divided by 2,880 is about 1,042 orders a minute on average. The peak was 7,000 a minute. 7,000 divided by 1,042 is about 6.7. So even inside the sale, the peak is far above the average.
Orders per second at the 2021 target
250
In December 2021, Myntra said its platform was ready for 15,000 orders a minute at peak. 15,000 divided by 60 is 250 orders a second.
Stock holds per second
~750
Assume 3 items per order. 250 orders a second times 3 is 750 stock holds a second, each on one size of one style. This is an interview assumption.
Product page reads per second
~12,500
Assume 50 product page views for every order placed. 250 times 50 is 12,500 product reads a second. These must come from caches, not the stock database.
Stock rows
up to 120 million
Assume 1 million styles live in the sale, each in 6 sizes. That is 6 million SKUs. Assume stock in 20 warehouses. 6 million times 20 is 120 million rows at most. Most rows are zero, so the real number is smaller.
Returns after one big sale
~2.25 million pickups (illustration)
Assume a sale ships 9 million items and 25% come back. That is 2,250,000 return pickups. Each one is a refund, a quality check and a restock. 25% is an assumption for this exercise, not a Myntra figure.
High-level architecture
Split Myntra into a read side and a write side. The read side is browsing: the catalog, search, product pages and prices. It is read far more than it is changed. So it lives in caches and a search index, close to users. The write side is buying: cart, stock holds, payment and orders. It is small in volume but must be exact. Stock is kept per SKU, which means one style in one size, per warehouse or store. A stock service is the only thing that changes those counts. Prices live in a price book. Each price has a time it starts. The sale prices are loaded days before, with a start time of the sale minute. So at that minute nothing is written. Every server just starts reading the next price. Orders go to an order service. It picks where to ship from, using stock, distance and how busy each warehouse is. Returns are a flow of their own. It books a pickup, checks the item, pays the refund and puts the stock back. Events between these services go through a queue, so a slow part never blocks checkout.
In a real interview, sketch this on the whiteboard before diving into any single box.
One sale order, end to end
The sale opens at 12 noon. A customer has a pair of shoes in size 9 in her cart.
- 1
The page loads
The product page comes from a cache. The price comes from the price book, which already holds the sale price with a start time of 12:00. At 12:00:00 every server shows it.
- 2
She checks out
The stock service holds one unit of size 9 with one update. It only works if a unit is free. If not, she is told that size just sold out.
- 3
She pays
The payment is sent with an idempotency key. A retry after a timeout cannot charge her twice.
- 4
The order is placed
The hold becomes an order. The order service picks the warehouse or store that has size 9 and is closest.
- 5
It ships
The chosen site packs it and hands it to a courier. Tracking updates flow back through the queue.
- 6
If it comes back
A pickup is booked. The item is checked. Only then is the refund paid and size 9 put back on sale.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Catalog and search
Styles, sizes, images and attributes, in a search index with filters. It is read-heavy and can be a few seconds behind. Size filters read the fast stock view, not the stock database.
Price book
Every price has a start time and an end time. Sale prices are loaded early with the sale's start time. At the sale minute, servers simply read the next row. No mass update happens under load.
Stock service (per SKU, per site)
The only thing that changes stock. It keeps on-hand and held counts for each size at each warehouse or store. A hold is one conditional update, so the last unit is sold once.
Fast stock view
A cached copy of which sizes are in stock, built from stock events. Product pages read it. It can be a moment behind; the hold at checkout is the real check.
Cart and checkout
The cart is a list, not a promise. Stock is held only at checkout, for a few minutes. The price is checked again at checkout, because the cart may have been filled before the sale.
Order routing
Picks where to ship each item from: a warehouse or a brand store. It weighs stock, distance and how busy each site is. One order may become two parcels.
Returns service
Books a reverse pickup and records the quality check. Then it pays the refund to the original payment method and returns the item to stock. Each step is a state, so nothing is paid twice.
Size suggestion
Suggests a size from the customer's past buys and the reasons for past returns. It is optional. If it is slow or down, the page shows without it.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
stylesstyle_id (PK)brand_idcategoryattributes (json)size_chart_idOne row per style. Read from the search index and caches, almost never from the database at peak.
skussku_id (PK)style_idsizebarcodeOne row per style and size. A shirt in six sizes is six SKUs. Stock, holds and orders all point here.
stocksite_idsku_idon_handheldversionSplit by sku_id. Sellable stock is on_hand minus held. A site is a warehouse or a store.
pricessku_idprice_paisemrp_paisestarts_atends_atcampaign_idThe price book. The live price is the row whose time range contains now. Sale rows are loaded days early.
orders / order_itemsorder_id (PK)customer_idsku_idsite_idprice_paisestateThe price paid is copied into the order item. A later price change never changes a past order.
returnsreturn_id (PK)order_item_idreasonstate (requested, picked, checked, refunded, restocked)refund_idOne row per returned item, moving through states. The refund uses an idempotency key made from return_id.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
The sale starts at one exact minute
Most traffic rises like a curve. A sale rises like a wall. People wait with full carts, and at the start minute they all press buy. In 2016, Myntra's peak was 6.7 times its own sale average. So plan for the wall, not the average. Scale servers up before the start, on a schedule, because autoscaling reacts too late to a wall. Warm the caches with the sale's top styles and their prices. Load test at the expected peak, then above it. Decide early what to switch off at the peak: size suggestions, recently viewed items and some reports can wait. If the crowd is still too big, a waiting room lets people in at a steady rate. That is better than a site that fails for everyone.
Stock per size
A style is what you see on the page. A SKU is the style in one size. Stock is kept per SKU, and per site. So one shirt can be sold out in M and full in XL. This changes the page and the checkout. The page must show which sizes are left, and it reads that from a fast cached view. The checkout must hold one unit of one size exactly once. That is one update: add one to held, but only if on_hand minus held is at least one. If the update changes no row, that size just sold out. Popular sizes in top deals become hot rows at the peak. Splitting stock by sku_id spreads them over many shards. For the very hottest SKUs, the stock can be split into a few buckets, each holding part of the units.
UPDATE stock
SET held = held + 1, version = version + 1
WHERE site_id = $1 AND sku_id = $2
AND on_hand - held >= 1
RETURNING version; -- no row: this size just sold outPrices that change at one instant
At the sale minute, millions of prices change. The slow way is a big update job at that minute. It writes to the database just as the crowd arrives. Caches expire one by one, so some pages show old prices and some new. The better way is a price book. Every price row has a start time and an end time. The sale rows are loaded days before, with the sale's start time. Caches hold both rows. At the start minute, every server simply picks the row whose time has come. Nothing is written under load. The order copies the price it was sold at. So if a price is wrong and fixed later, past orders do not change. Server clocks must agree, so they all use network time.
A cart is not a promise
During a sale, many people fill carts hours before it starts. If a cart held stock, the best sizes would be locked by people who never buy. So the cart is only a list. Stock is held at checkout, for a few minutes. The price is checked again at checkout too. A cart filled before the sale shows the sale price once the sale starts. If a size sold out while it sat in the cart, the customer is told before paying, not after. This keeps stock moving to people who are ready to pay.
Shipping from warehouses and stores
In December 2021, Myntra said it had brought over 350 brands and 2,900 stores into its omnichannel delivery model. For the design, a store is just another site that holds stock. The order service picks a site for each item. It looks at which sites have that size and how far they are. It also checks how busy each one is. A store that is far behind on packing is skipped. One order may become two parcels, from two sites. Stores also sell over the counter, so their counts drift. So a store's stock is shown with a safety margin, such as hiding the last unit online.
Returns are a normal path
In fashion, items come back because of size, fit or colour. So returns are a full flow, not an exception. A return moves through states: requested, picked up, checked, refunded and restocked. The item goes back on sale only after it is checked, not when the pickup is booked. The refund goes to the original payment method. It uses an idempotency key made from the return id. So a retry never pays twice. The reasons for returns are data. Too small, too big and not as pictured feed the size suggestion and the brand's size chart. That is how returns slowly reduce returns.
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.
Hold stock at checkout versus in the cart
Holding in the cart feels safer for the shopper. But in a sale, carts filled hours early would lock the best sizes. Holding only at checkout keeps stock for people ready to pay. The cost is that a size can sell out while it sits in a cart.
Price book with start times versus updating prices at the sale minute
A big update is simple to write. But it adds load at the worst moment and leaves caches mixed. A price book with start times needs more storage and care with clocks. In return, the sale minute writes nothing.
Ship from stores versus warehouses only
Stores add stock close to customers and sell sizes a warehouse may lack. But store counts drift because of walk-in sales, and stores pack more slowly. A safety margin and a check on store backlog limit the risk.
Pre-scale before the sale versus autoscaling
Autoscaling saves money on normal days. But a sale arrives as a wall, faster than new servers can start. Scaling up on a schedule before the start costs more for a few hours and avoids a failed opening.
Restock at pickup versus after the check
Restocking at pickup puts the item back on sale sooner. But a damaged or wrong item would then be sold again. Waiting for the check is slower and safer.
Free PDF · 18 pages
Get the free System Design Interview Cheat Sheet
The interview in seven stages, the numbers worth knowing by heart, and twelve classic systems on one page each, every line linked to the lesson it comes from.
Follow-up questions to expect
After the main design, the interviewer usually picks one part and asks more. Here is what to say.
How do you stop bots from buying the top deals at the sale start?
Put a rate limit per account and per device on checkout. Require a logged-in account with some history for the hottest deals. Use a waiting room that lets people in at a steady rate. Watch for many accounts sharing one card or address, and cancel those orders before they ship.
How would you show "only 2 left" for a size?
Read it from the fast stock view, which is built from stock events and can be a moment behind. Show a low number only below a threshold. The checkout hold is the real check, so a stale "2 left" never causes an oversell.
What happens if payment succeeds but the order service is down?
The payment carries an idempotency key, and the payment event goes to a queue. When the order service is back, it reads the event and creates the order once. If the stock hold expired meanwhile and the size is gone, the payment is refunded automatically.
How Myntra actually does it
Myntra has not published how its systems are built in the sources read for this page. So the design here fits public numbers; it is not a description of Myntra's code. The numbers come from news reports. In July 2016, Retail4Growth reported three million orders over two days. It reported 7,000 orders a minute at the peak, with the app bringing about 90% of revenue. In December 2021, the Free Press Journal reported that the platform was ready for 15,000 orders a minute at peak. The same report covered 350 brands and 2,900 stores in its omnichannel model. Flipkart bought Myntra in May 2014. For the general flash sale, see the Flipkart page.
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 Warming
foundation / caching strategies
Cache Stampede Prevention
foundation / caching strategies
Load Shedding
advanced / reliability resilience
Database Sharding
foundation / database fundamentals
Idempotency Keys
intermediate / api design protocols
Search Engines (Elasticsearch, Solr)
intermediate / database types storage
State Machine
advanced / distributed systems core
Message Queues
intermediate / messaging event systems
System design interviews at Indian tech companies
28 walkthroughs of the products Indian interviewers ask about, each with the real scale numbers, the architecture and the trade-offs that company had to make.
Food delivery and quick commerce
Payments and fintech
E-commerce
- Flipkart system design
- Meesho system design
- Nykaa system design
- Myntra system design (this page)
- Lenskart system design
Travel and ticketing
Rides, logistics and services
Streaming and gaming
Frequently asked questions
Go deeper
This guide is built on these 6 lessons. Each one teaches one piece of the Myntra design above, step by step.
- Cache WarmingSystem Design · caching strategies · 25 min
- Cache Stampede PreventionSystem Design · caching strategies · 25 min
- Load SheddingSystem Design · reliability resilience · 20 min
- Database ShardingSystem Design · database fundamentals · 35 min
- Idempotency KeysSystem Design · api design protocols · 18 min
- Search Engines (Elasticsearch, Solr)System Design · database types storage · 22 min
Practice with 770 system design lessons
Lifetime access for ₹1,111 in India or $25 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.
This one question is not enough for the interview.
Get all 200 questions in the System Design and Distributed Systems pack
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
NEWSystem Design Hands-On
Included in the System Design course: real systems, built live
Postgres Sharding: Complete Hands-On (PgBouncer + Citus). 2 h 36 min and 20 chapters: one PostgreSQL loaded until it breaks, then four shards behind a router you write, PgBouncer and Citus, with the 139-page slide deck. The first 15 minutes are free to watch.