Amazon / E-commerce Platform

Designing an Amazon-like e-commerce platform is a classic system design problem because it combines different workloads: product discovery, search, shopping carts, inventory, checkout, payments, orders, fulfillment, reviews, and recommendations.

The key challenge is that these workflows require different consistency guarantees.

Product descriptions, search results, recommendations, and review counts can tolerate brief staleness. But overselling inventory, creating duplicate orders, or charging a customer twice are correctness failures.

Scope: This is a conceptual Amazon-like e-commerce architecture for system design interviews. It does not describe Amazon's private production architecture.

What Are We Designing?

At a high level, an e-commerce platform helps customers discover products and safely complete purchases.

Customer
   ↓
Browse / Search
   ↓
Product Details
   ↓
Add to Cart
   ↓
Checkout
   ↓
Reserve Inventory
   ↓
Create Order
   ↓
Process Payment
   ↓
Confirm Order
   ↓
Fulfillment

The main systems involved are:

Catalog
Search
Pricing
Cart
Inventory
Checkout
Orders
Payments
Fulfillment
Reviews
Recommendations
Notifications

The core transaction is:

Find a product → add it to the cart → safely reserve inventory → create a durable order → process payment.

Functional Requirements

The platform should support the core customer shopping journey.

• Browse and search products.

• View product details, prices, and availability.

• Add, update, and remove cart items.

• Checkout with shipping and payment information.

• Place and pay for orders.

• Track and cancel eligible orders.

• View order history.

• Support returns and refunds.

Marketplace extensions can include third-party sellers, reviews, wishlists, recommendations, coupons, and multiple warehouses.

Non-Functional Requirements

The system should scale read-heavy workloads while protecting correctness-critical operations.

• High availability and low browse/search latency.

• High read scalability.

• Correct inventory reservation.

• Reliable and idempotent checkout and payments.

• Durable order state.

• Horizontal scalability and fault isolation.

• Security and auditability.

Different workflows require different consistency guarantees:

Search / Recommendations / Reviews
→ Eventual consistency is usually acceptable

Inventory / Orders / Payments
→ Stronger correctness guarantees are required

Scale Estimation

Hypothetical numbers help identify the dominant workloads and potential bottlenecks.

Product views:

100M × 20
= 2 billion product views/day
≈ 23,000 reads/sec average

Searches:

100M × 5
= 500 million searches/day
≈ 5,800 searches/sec average

Orders:

5M / 86,400
≈ 58 orders/sec average

Peak traffic can be several times higher, especially during major sales and flash-sale events.

The system is massively read-heavy, while checkout has lower volume but much stricter correctness requirements.

High-Level Architecture

The architecture separates read-heavy product discovery from correctness-heavy purchasing.

                         CUSTOMER
                            ↓
                       API GATEWAY
                            ↓
          +-----------------+-----------------+
          |          |          |            |
          ↓          ↓          ↓            ↓
       Catalog     Search      Cart       Checkout
       Service     Service    Service      Service
          ↓          ↓          ↓          |
     Catalog DB  Search Index Cart DB      |
                                           ↓
                                      Pricing Service
                                           ↓
                                     Inventory Service
                                           ↓
                                       Order Service
                                           ↓
                                      Payment Service
                                           ↓
                                        Order DB

Asynchronous workflows are decoupled:

Order Events
     ↓
Event Bus
  /    |        |          \
 ↓     ↓        ↓           ↓
Fulfillment  Notifications  Analytics  Recommendations

Optional systems should not unnecessarily block checkout.

Core Data Model

A product contains common descriptive information.

Product
-------
product_id
title
description
brand
category_id
attributes
status

However, a product is not always the actual purchasable unit.

For example:

Phone
 ├── Black / 128 GB
 ├── White / 128 GB
 └── Black / 256 GB

Each purchasable variation is a SKU.

SKU
---
sku_id
product_id
attributes

Inventory and pricing normally operate at the SKU level.

For a marketplace, introduce an Offer:

Offer
-----
offer_id
sku_id
seller_id
price
condition
fulfillment_type
status

Multiple sellers can therefore sell the same SKU with different prices and fulfillment options.

Product vs SKU vs Offer

An e-commerce platform separates Product, SKU, and Offer because each represents a different level of what the customer sees and buys.

Product
   ↓
SKU
   ↓
Offer

For example, one product can have multiple SKUs:

iPhone 16
   ├── Black / 128 GB
   ├── Black / 256 GB
   └── White / 256 GB

In a marketplace, the same SKU can also have multiple seller offers:

Black / 256 GB
   ├── Seller A → ₹80,000
   ├── Seller B → ₹79,500
   └── Seller C → ₹81,000

So the relationship is:

Product = what the item is → SKU = which variation → Offer = who is selling that variation and under what terms.

This separation allows catalog, inventory, pricing, and seller systems to evolve independently.

Catalog Service

Catalog Service owns structured product information such as title, description, brand, category, attributes, images, and variants.

A typical API is:

GET /v1/products/{product_id}

Conceptual response:

{
  "product_id": "P123",
  "title": "Wireless Headphones",
  "brand": "Example",
  "variants": []
}

Catalog data is read far more frequently than it changes, making it highly cacheable.

Product Images and CDN

Product images should be stored in object storage rather than directly in the database.

Catalog DB
    ↓
Image Metadata / Object Key
    ↓
Object Storage
    ↓
CDN
    ↓
Customer

The database stores image metadata and object references, while object storage stores the actual images. A CDN delivers images closer to customers for faster loading and reduced backend load.

Database = metadata, Object Storage = images, CDN = fast delivery.

Search Architecture

Search is a specialized read workload and should not depend on expensive full-text queries against the primary catalog database.

Catalog Change
      ↓
Change Event
      ↓
Search Indexer
      ↓
Search Index

The index can contain:

• Title and description.

• Brand and category.

• Attributes and keywords.

• Availability signals.

• Price ranges.

• Popularity and ranking signals.

Search therefore becomes an optimized read model derived from authoritative catalog data.

Search Consistency

Suppose a seller changes a product title:

Catalog Updated
      ↓
Indexing Event
      ↓
Search Index Updated

For a short period:

Product API → New Title
Search      → Old Title

This brief inconsistency is usually acceptable.

Search should not be treated as the authoritative catalog database.

Search Ranking

Search ranking can consider:

Query
 ↓
Candidate Retrieval
 ↓
Filtering
 ↓
Ranking
 ↓
Top K Products

Signals may include text relevance, availability, price, popularity, ratings, delivery speed, conversion signals, personalization, and seller quality.

Product Page Aggregation

A product page may need information from several services.

Instead of making the frontend coordinate many independent backend calls, a Product Page Service or BFF can aggregate them.

Client
  ↓
Product Page Service
  ├── Catalog
  ├── Pricing
  ├── Inventory
  ├── Reviews
  └── Recommendations

Dependencies should be classified as critical or optional. Recommendation failure, for example, should not prevent the product page from loading.

Caching Product Data

Catalog information is an excellent caching candidate.

Catalog Service
      ↓
    Cache
   /     \
 HIT     MISS
 ↓         ↓
Return   Catalog DB

Good cache candidates include product metadata, categories, seller metadata, and popular products.

Dynamic data such as inventory requires more care.

A cached In Stock label is useful for display, but checkout must still perform an authoritative inventory reservation.

Shopping Cart

The cart represents the customer's current purchase intent.

Typical APIs:

GET /v1/cart
POST /v1/cart/items
PATCH /v1/cart/items/{sku_id}
DELETE /v1/cart/items/{sku_id}

A simplified model:

Cart
----
cart_id
user_id
updated_at

CartItem
--------
sku_id
quantity
added_at

The most important rule is:

Adding an item to the cart normally does not reserve inventory.

If the last item were permanently reserved whenever someone added it to a cart, abandoned carts could prevent real customers from purchasing it.

Therefore:

Cart
≠
Inventory Reservation

Availability must be validated again during checkout.

Cart Storage

Cart access is commonly keyed by user_id, making it a natural partition key.

A fast distributed key-value or document store can work well, but cart state should not automatically be treated as disposable cache data.

Users often expect their carts to survive restarts and remain available across devices.

Guest Cart

An anonymous user's cart may later need to merge with their account cart.

Guest Cart
    +
Account Cart
    ↓
   Merge

Conflicts can include the same SKU, different quantities, changed prices, or unavailable products.

The exact merge policy is a product decision.

Pricing Service

Pricing can vary by SKU, seller, region, promotions, coupons, customer eligibility, and currency.

The cart may store a price snapshot for display, but checkout should revalidate the current authoritative price unless a price lock is guaranteed.

Cart Price
→ Display Snapshot

Checkout Price
→ Authoritative Price

Inventory Service

Inventory tracks available and reserved stock for each SKU, often across multiple warehouses.

Inventory
---------
sku_id
warehouse_id
on_hand
reserved

available = on_hand - reserved

At scale, the same SKU may exist in multiple fulfillment locations:

SKU123
 ├── Warehouse A → 10
 ├── Warehouse B → 7
 └── Warehouse C → 3

The system can select inventory based on availability, customer location, delivery time, and fulfillment cost.

Preventing Overselling

Suppose only one unit remains and two customers attempt checkout simultaneously.

Customer A ──┐
             ├── Last Unit
Customer B ──┘

A naive read-then-write approach can allow both customers to observe stock as available.

Use an atomic conditional reservation instead.

UPDATE inventory
SET reserved = reserved + 1
WHERE sku_id = ?
  AND on_hand - reserved >= 1;

Only a successful reservation proceeds.

Optimistic concurrency or another serialization mechanism can also be used.

The important invariant is:

Never reserve more sellable units than inventory policy permits.

A queue alone does not automatically guarantee this invariant.

Inventory Reservation

Checkout normally creates a temporary reservation.

AVAILABLE
    ↓
RESERVED
    ↓
SOLD

A reservation can contain:

reservation_id
order_id
sku_id
quantity
expires_at

This prevents another checkout from taking the inventory while payment is in progress.

Reservation Expiry

Reservations must be bounded.

Reservation
     ↓
Payment Succeeds?
   /           \
 Yes            No
 ↓              ↓
Commit         Release
Stock          Reservation

If the customer disappears or payment permanently fails, the reservation eventually expires and stock becomes available again.

Checkout Service

Checkout coordinates the purchase workflow.

Cart
 ↓
Validate Products
 ↓
Get Current Prices
 ↓
Validate Address
 ↓
Calculate Shipping / Tax
 ↓
Reserve Inventory
 ↓
Create Pending Order
 ↓
Process Payment
 ↓
Confirm Order

These steps span independent systems.

Trying to hold one giant distributed ACID transaction across inventory, orders, payments, coupons, and fulfillment would create tight coupling, long-lived locks, poor availability, and difficult recovery.

External payment providers may not participate in such a transaction at all.

Checkout Saga

A Saga-style workflow uses local transactions and explicit compensation.

Create Checkout
      ↓
Reserve Inventory
      ↓
Create Pending Order
      ↓
Process Payment
      ↓
Confirm Order
      ↓
Commit Reservation

If payment permanently fails:

Payment Failed
      ↓
Cancel Pending Order
      ↓
Release Inventory

Every step and compensation should be retryable and idempotent where appropriate.

Order State Machine

Orders should use explicit states rather than loosely related Boolean flags.

PENDING
   ↓
PAYMENT_PROCESSING
   ↓
CONFIRMED
   ↓
FULFILLING
   ↓
SHIPPED
   ↓
DELIVERED

Alternative transitions include:

PENDING → CANCELLED

PAYMENT_PROCESSING → PAYMENT_FAILED

CONFIRMED → CANCELLATION_REQUESTED

Returns and refunds are better modeled as separate workflows rather than forcing every lifecycle into one status field.

Order Creation Idempotency

A customer may tap Place Order, receive a network timeout, and retry even though the first request succeeded.

Without protection:

Retry
 ↓
Order 1 + Order 2
 ↓
Possible Duplicate Payment

Use an idempotency key:

POST /v1/orders
Idempotency-Key: checkout_xyz

Persist a mapping such as:

(customer_id, idempotency_key)
          ↓
       order_id

Repeated requests return the same logical result.

Payment Reliability and Idempotency

Payment should have its own stable identifiers.

order_id
payment_attempt_id
provider_reference

A payment timeout does not necessarily mean the payment failed.

Timeout
≠
Payment Failed

The provider may have processed the charge while the response was lost.

Before charging again:

Check Provider Status
        ↓
Reconcile
        ↓
Retry Safely If Needed

Never blindly retry monetary side effects.

Order and Payment Are Separate State Machines

Order and payment lifecycles should not be collapsed into one status.

Payment may have:

CREATED
AUTHORIZED
CAPTURED
FAILED
REFUNDED
PARTIALLY_REFUNDED

Order may have:

PENDING
CONFIRMED
SHIPPED
DELIVERED
CANCELLED

A state such as:

Order   = CANCELLED
Payment = REFUND_PENDING

can be completely valid while compensation is still running.

Transactional Outbox

Suppose Order Service commits an order and then tries to publish an event.

Update Order
    ↓
Commit
    ↓
CRASH
    ↓
Publish Event Never Happens

Fulfillment may never learn about the confirmed order.

Use a transactional outbox:

BEGIN;

UPDATE orders
SET status = 'CONFIRMED';

INSERT INTO outbox
(event_id, type, payload)
VALUES (..., 'OrderConfirmed', ...);

COMMIT;

The order update and outbox event are committed in the same durable transaction.

An asynchronous publisher then sends the event to the broker.

Event-Driven Order Processing

Once an order is confirmed:

OrderConfirmed
      ↓
   Event Bus
  /    |       |          \
 ↓     ↓       ↓           ↓
Fulfillment  Notifications Analytics  Recommendations

This provides loose coupling, independent scaling, retryability, and failure isolation.

The order API does not need to wait for every downstream system.

Delivery Semantics

Event delivery is commonly at least once, so consumers must tolerate duplicates.

OrderConfirmed(O123)
        ↓
Delivered More Than Once
        ↓
Idempotent Consumer

A fulfillment consumer can deduplicate by event_id or enforce a business invariant such as:

One fulfillment workflow per order

This provides effectively-once business behavior over at-least-once delivery.

Multiple Warehouses and Fulfillment

Inventory can exist across many warehouses.

The fulfillment system may choose between:

One Warehouse
→ Fewer packages

Multiple Warehouses
→ Potentially faster or more available fulfillment

Selection can consider:

• Inventory availability.

• Delivery ETA.

• Shipping cost.

• Warehouse capacity.

• Number of packages.

• Inventory balancing.

One customer order may therefore produce multiple shipments.

Order O123
   ├── Shipment S1 → SKU A
   └── Shipment S2 → SKU B, SKU C

Therefore:

Order
≠
Shipment

Fulfillment can publish events such as ShipmentCreated, ShipmentDispatched, and ShipmentDelivered, which Order Service consumes to expose customer-friendly status.

Cancellation, Returns, and Refunds

Cancellation is a distributed workflow rather than simple row deletion.

Cancellation Request
        ↓
Check Eligibility
        ↓
Stop Fulfillment
        ↓
Release Inventory
        ↓
Void / Refund Payment
        ↓
Update Order

Returns are a separate lifecycle:

Return Request
      ↓
Eligibility
      ↓
Return Authorization
      ↓
Item Returned
      ↓
Inspection
      ↓
Refund
      ↓
Inventory Disposition

Returned inventory may become sellable, damaged, refurbished, or discarded.

Flash Sale Architecture

Flash sales create a very different workload.

Suppose millions of users attempt to buy the same limited-stock SKU simultaneously.

Problems include hot inventory keys, database contention, retry storms, bots, queue overload, and payment spikes.

Use admission control:

Millions of Requests
        ↓
Rate Limit / Bot Protection
        ↓
Waiting Room / Admission
        ↓
Reservation Workers
        ↓
Valid Winners
        ↓
Checkout

The goal is to prevent millions of concurrent requests from hammering the same scarce inventory resource.

Hot SKUs

A single popular SKU can become a hot key.

Possible mitigations include controlled inventory buckets or other specialized reservation strategies, but these make the global stock invariant harder to maintain.

Introduce them only when real contention justifies the complexity.

A waiting-room token should be short-lived, signed, and safe against replay. Admission alone should not imply guaranteed inventory unless it is explicitly tied to a reservation.

Recommendations

Recommendations are naturally asynchronous and should remain outside the critical checkout path.

User Events
    ↓
Event Stream
    ↓
Feature Pipeline
    ↓
Candidate Generation
    ↓
Ranking
    ↓
Recommendations

Signals can include product views, searches, purchases, cart additions, wishlists, and ratings.

Recommendation failure must not block product browsing or checkout.

Reviews and Ratings

Reviews can be handled by a separate service.

Review
------
review_id
product_id
user_id
rating
text
status
created_at

Aggregated ratings should not require scanning millions of reviews on every product-page request.

ReviewCreated
      ↓
Rating Aggregator
      ↓
Rating Summary

Review moderation can also run asynchronously:

SUBMITTED
    ↓
MODERATION
   /    \
  ↓      ↓
PUBLISHED REJECTED

Notifications

Order events can trigger asynchronous notifications.

OrderConfirmed
OrderShipped
OrderDelivered
RefundCompleted
       ↓
Notification Service
   /      |       \
 Push    Email     SMS

Notification failures should not roll back confirmed orders.

The same pattern can support back-in-stock and price-drop notifications with appropriate batching and rate control.

Database Choices

A large e-commerce platform should not force every workload into one database technology.

Polyglot persistence should be driven by workload requirements, not technology fashion.

Partitioning

Partition keys should follow access patterns while avoiding hot spots.

Examples:

Operational queries that do not align with the primary partition key may require secondary indexes or dedicated read models.

Cache Invalidation and Hot Products

Different product fields need different freshness guarantees.

Description
→ TTL / Eventual Invalidation

Checkout Price
→ Revalidate

Inventory
→ Authoritative Reservation

A viral product can also cause a cache stampede when a popular cache entry expires.

Mitigations include:

• Request coalescing.

• Jittered TTLs.

• Background refresh.

• Stale-while-revalidate.

• Hot-key replication.

The cache should improve performance, not become the source of truth for critical purchase decisions.

Graceful Degradation

Optional dependencies should fail independently.

If recommendations fail:

Product Details ✓
Price           ✓
Inventory       ✓
Add to Cart     ✓
Recommendations ✗

The page should still work.

Similarly, delayed analytics or notification infrastructure should not make checkout unavailable.

Classify dependencies as critical or optional and define fallbacks accordingly.

Multi-Region Architecture

Read-heavy systems such as catalog and search can be replicated geographically.

                   Global Routing
                         ↓
             +-----------+-----------+
             ↓                       ↓
          Region A                 Region B
             ↓                       ↓
      Catalog / Search        Catalog / Search
      Cart / APIs             Cart / APIs

Orders and especially inventory require more careful ownership.

Physical inventory naturally belongs to a fulfillment location.

Warehouse W1 Inventory
          ↓
Authoritative Region R1

Other regions may read cached availability, but final reservation can route to the authoritative inventory owner.

This avoids two independent regions selling the same final unit without coordination.

Security

E-commerce systems handle sensitive customer and financial information.

Protect:

• Account credentials.

• Addresses.

• Payment information.

• Order history.

• Seller data.

• Inventory administration.

Use TLS, authentication, authorization, encryption at rest where appropriate, secure secret management, audit logging, rate limiting, fraud controls, and least privilege.

Minimize the payment data stored directly by the platform. Tokenization and payment-provider integrations can reduce exposure.

Observability

Monitor both technical health and business correctness.

Important signals include:

• Search and product-page latency.

• Search indexing lag.

• Cache hit rate.

• Checkout latency and failures.

• Inventory reservation failures.

• Reservation expiry rate.

• Order creation success.

• Payment failures and ambiguous payments.

• Refund latency.

• Broker lag and queue depth.

• Database latency and hot partitions.

• Regional error rates.

Business invariants are especially important.

For example:

Confirmed Quantity
must not exceed
Permitted Sellable Inventory

Complete Browse Flow

The browse path is optimized for fast reads and graceful degradation.

Customer
   ↓
Search Query
   ↓
Search Service
   ↓
Search Index
   ↓
Product IDs
   ↓
Product Page Service
   ├── Catalog
   ├── Pricing
   ├── Availability
   ├── Reviews
   └── Recommendations
   ↓
Product Page

Optional systems should have fallbacks.

Complete Checkout Flow

The checkout path prioritizes correctness over pure read performance.

Customer
   ↓
Checkout
   ↓
Validate Cart
   ↓
Current Price + Address + Shipping
   ↓
Reserve Inventory
   ↓
Create PENDING Order
   ↓
Process Payment
   ↓
   +------ Failure ------> Cancel / Release Reservation
   |
 Success
   ↓
Confirm Order
   ↓
Commit Inventory
   ↓
OrderConfirmed Event
   ├── Fulfillment
   ├── Notifications
   └── Analytics

The exact order of payment authorization, order creation, inventory reservation, and payment capture can vary according to business requirements.

The important part is that failures and compensation are explicit.

Important Failure Scenarios

A strong system design should explain recovery behavior, not only the happy path.

Retries and compensations should themselves be idempotent.

Marketplace Extension

A marketplace introduces sellers and offers.

Product
   ↓
  SKU
   ↓
+------+-------+------+
|      |       |      |
Seller A Seller B Seller C
₹999    ₹950    ₹1,050

Each offer may differ in price, stock, condition, delivery promise, seller quality, and fulfillment method.

Seller updates can publish events:

OfferUpdated
     ↓
Event Bus
 ├── Catalog Read Model
 ├── Search Index
 ├── Pricing
 └── Cache Invalidation

This extension adds substantial complexity beyond a single-retailer e-commerce system.

High-Level Design vs Low-Level Design

HLD focuses on the overall system architecture, while LLD focuses on internal objects, relationships, and behavior.

For an Amazon system design interview, start with HLD and move into LLD only when the interviewer asks for deeper implementation details.

How the Architecture Evolves

The architecture should become more complex only when traffic or correctness requirements justify it.

Each new component should solve a concrete scaling, reliability, or correctness problem.

Key Trade-Offs

The main design decisions come from choosing where speed, availability, freshness, and correctness matter most.

• Availability vs inventory correctness: Browse paths should remain highly available, while final reservation must protect stock invariants.

• Freshness vs search performance: Search indexes scale retrieval but may briefly lag catalog changes.

• Cart convenience vs stock utilization: Reserving at Add to Cart improves certainty but can lock scarce stock unnecessarily.

• Synchronous vs asynchronous workflows: Events improve isolation and scalability but introduce eventual consistency and duplicate-delivery concerns.

• Global writes vs regional ownership: Clear inventory ownership simplifies scarce-stock correctness but may require cross-region coordination.

Amazon System Design Interview Questions

These questions cover the most important e-commerce architecture decisions.

Q1. How would you design an Amazon-like e-commerce platform?

Separate read-heavy product discovery from transactional purchasing. Use catalog and search systems for discovery, durable carts for purchase intent, authoritative inventory reservations, checkout orchestration, durable orders, and idempotent payments.

Q2. How do you prevent overselling?

Use atomic conditional inventory reservations or another serialization mechanism that guarantees reservations cannot exceed sellable stock.

Q3. Does Add to Cart reserve inventory?

Usually no. Cart represents purchase intent. Reserve inventory near checkout for a bounded period unless business requirements specify otherwise.

Q4. How do two customers compete for the final item?

Both can attempt reservation, but the authoritative atomic inventory operation allows only one valid reservation to succeed.

Q5. Why do we need inventory reservations?

They temporarily protect inventory while checkout and payment are in progress.

Q6. What happens when a reservation expires?

Release the quantity unless the order has already committed the reservation.

Q7. How would you design the shopping cart?

Use durable cart storage primarily keyed by user/account, support safe item updates, and revalidate price and availability at checkout.

Q8. How would you design product search?

Build a dedicated search index asynchronously from authoritative catalog changes.

Q9. Why not search the catalog database directly?

Search engines are optimized for full-text retrieval, ranking, filtering, and faceting, while the catalog database is optimized for authoritative product data.

Q10. How do you handle price changes in the cart?

Treat cart prices as display snapshots and revalidate authoritative pricing during checkout unless a price lock is guaranteed.

Q11. How do you prevent duplicate orders?

Use a client/checkout idempotency key and persist its mapping to the resulting order.

Q12. How do you prevent duplicate charges?

Use payment-level idempotency and stable provider references. Reconcile ambiguous outcomes before retrying.

Q13. What if payment succeeds but the response is lost?

Treat the result as unknown, query/reconcile with the provider, and avoid blindly charging again.

Q14. What is a checkout Saga?

It is a sequence of local transactions across services with compensating actions when later operations fail.

Q15. Why not use one distributed transaction for checkout?

It creates tight coupling, long-lived locks, poor availability, and does not integrate cleanly with external payment providers.

Q16. How do you handle flash sales?

Use rate limiting, bot protection, waiting rooms or admission control, queueing where appropriate, and carefully controlled inventory reservation.

Q17. How do you handle hot products?

Use CDN/cache for read traffic and introduce specialized contention controls for hot inventory only when needed.

Q18. How does order tracking work?

Order Service consumes fulfillment and shipment events and exposes a customer-friendly order state.

Q19. How do returns work?

Treat returns as a separate workflow covering eligibility, authorization, shipment, inspection, refund, and inventory disposition.

Q20. SQL or NoSQL?

Choose storage according to workload. Orders and payments need transactional guarantees, search needs a search index, media belongs in object storage, and other workloads can use appropriate distributed stores.

Q21. How do you make checkout reliable?

Use idempotency, explicit state machines, reservations, durable orders, payment reconciliation, retryable workflows, transactional outbox, and idempotent consumers.

Q22. How do you handle multiple warehouses?

Track inventory by SKU and fulfillment location, then choose fulfillment based on availability, delivery promise, cost, and operational capacity.

Q23. How do you scale globally?

Replicate read-heavy catalog and search data geographically while giving scarce physical inventory clear authoritative ownership.

Q24. What can be eventually consistent?

Search indexes, recommendations, review aggregates, popularity counters, and some displayed availability signals can tolerate brief staleness.

Q25. What requires stronger correctness?

Inventory reservation, order creation, payments, and critical order state transitions require stronger guarantees.

Common Mistakes

Avoid these common weaknesses in an Amazon system design interview:

• Designing the platform as simple CRUD tables.

• Reserving inventory indefinitely when an item enters the cart.

• Trusting cached availability during checkout.

• Ignoring concurrent purchases of the final unit.

• Assuming a payment timeout means failure.

• Retrying payments without idempotency.

• Treating the search index as authoritative catalog storage.

• Coupling notifications, recommendations, or analytics to checkout.

• Using distributed transactions everywhere instead of explicit workflows.

• Naming Kafka, Redis, Elasticsearch, or other technologies without explaining the problem they solve.

Technology choices should follow business invariants and workload requirements.

Final Amazon High-Level Architecture

The final architecture separates product discovery, transactional purchasing, media delivery, and asynchronous workflows.

                         CUSTOMER
                            ↓
                       API GATEWAY
                            ↓
        +-------------------+-------------------+
        |          |           |               |
        ↓          ↓           ↓               ↓
     Catalog     Search       Cart          Checkout
        ↓          ↓           ↓               |
   Catalog DB  Search Index  Cart DB            |
                                               ↓
                                         Pricing Service
                                               ↓
                                        Inventory Service
                                               ↓
                                          Order Service
                                               ↓
                                         Payment Service
                                               ↓
                                           Order DB

PRODUCT MEDIA

Catalog
   ↓
Object Storage
   ↓
CDN
   ↓
Customer

RELIABLE ORDER EVENTS

Order Service
      ↓
Order DB + Outbox
      ↓
Outbox Publisher
      ↓
Event Bus
  /       |          |             \
 ↓        ↓          ↓              ↓
Fulfillment  Notifications  Analytics  Recommendations
     ↓
Warehouse / Shipment

The central design principle is:

Scale product discovery for availability and speed, but protect checkout with stronger correctness around inventory, orders, and money.

That separation is the foundation of a scalable and reliable Amazon-like e-commerce system design.