Amazon E-commerce Platform – System Design Interview Preparation

Practice designing Amazon e-commerce platform. Cover product catalog, search, cart, checkout, inventory management, and order processing at scale.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Amazon design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Amazon is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Inventory consistency at checkout across warehouses, and a catalogue read path that must stay fast while the write path stays correct.

Scale to establish before drawing anything

Hundreds of millions of products; browse and search traffic is orders of magnitude above purchase traffic.
Order volume spikes 10x or more on sale days, with the spike concentrated into minutes.
Inventory is per warehouse, so "in stock" is a question about a location, not a product.

Core components

Catalogue service – Product data, read-heavy, cached and denormalised for display.
Search service – A separate inverted index with faceting. Updated asynchronously from the catalogue.
Inventory service – Per-warehouse counts with reservation at checkout. The system's consistency boundary.
Cart service – Session or user scoped, deliberately not reserving stock.
Order and payment services – Separated so a payment failure does not leave a half-written order.
Recommendation service – Offline-computed, served from a precomputed store.

Trade-offs to defend

Cart does not hold stock – Holding stock in carts would make a sale unusable. The cost is telling a customer at checkout that an item has gone, and that is the accepted trade.
Search index lag – A product updated now appearing in search in seconds is fine; in minutes is not. That window sizes your indexing pipeline.
Saga versus distributed transaction – Order, payment and inventory across services means compensating actions, not two-phase commit. Say what compensates what.

Follow-up questions to expect

A payment succeeds and inventory reservation fails. What does the customer see, and what reverses?
A flash sale puts 100,000 buyers on one SKU with 500 units. Describe the first second.
A price changes while an item sits in 50,000 carts. Which price applies, and where is that decided?