Design a read- and write-heavy product catalog
PremiumBackend systemHard
- Listing versions
- Optimistic concurrency
- Change data capture
Quick answer
This backend system interview question asks you to design a read- and write-heavy product catalog. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design a read- and write-heavy product catalog for a large marketplace, where merchants change listings all day and shoppers read them far more often. The hard part is one consistent listing state while updates arrive out of order, caches and search lag, and withdrawn products must vanish fast.
A listing belongs to one merchant and has a title, attributes, images, a price and a stock status. Merchants edit listings in a web console, through an API and through bulk feeds of up to 2 million rows. Every API update and feed row carries the time the merchant generated it, and console edits are stamped with the save time. Shoppers see listings on product pages, in search results and in their cart. Trust and safety staff can withdraw any listing (unsafe, recalled or illegal), and merchants can delist and relist their own.
What must a read- and write-heavy product catalog do?
- Merchant writes: Merchants create, edit, delist and relist listings from the console, the API or a bulk feed; each change is fully applied or rejected.
- Ordered state: When two updates to one listing arrive out of order, the newer one wins everywhere, including caches and the search index.
How well must it do it?
- Freshness: Price and state changes appear on product pages within 5 seconds and in search within 60 seconds, at p99.
- Read latency: Product page reads take under 50 ms at p99, and stay available when the write path is down.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Listing versions
- Optimistic concurrency
- Change data capture
- Cache invalidation
- Search indexing
- Listing withdrawals
How you’ll practise
- Requirements
- Estimate
- API and data
- High-level design
- Deep dives
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any backend system design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a backend system question. You design a read- and write-heavy product catalog and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team