AMAZON - SYSTEM DESING - MICROSERVICE SYSTEM DESIGN - PERFECT EXAMPLE

 

🛒 Amazon System Design — Interview Class Notes

Below is a structured, interview-ready version of your transcript, with the architecture and important reasoning filled in.

---

1. Problem Statement

Design a large-scale Amazon-like e-commerce platform where:

• Sellers list products

• Customers search and browse products

• Customers add products to cart

• Customers place orders

• Payments are processed

• Inventory is maintained

• Delivery/ETA is shown

• Customers can view order history

• System survives huge traffic spikes such as Black Friday

The biggest challenge is:

How do we maintain availability and low latency at massive scale while guaranteeing correctness for inventory, orders, and payments?

---

2. Three Core Assumptions ⭐

These are the first things to establish in the interview.

① Read-heavy or Write-heavy?

Read-heavy

There are significantly more buyers than sellers.

Typical traffic:

Millions of users
      │
      ├── Browse
      ├── Search
      ├── View Product
      ├── Check Price
      └── Check Reviews
             │
             ▼
           READS

Writes include:

• Product creation

• Inventory updates

• Orders

• Payments

• Reviews

But overall:

Reads >> Writes

---

3. Distributed or Single Server?

Distributed system

Amazon-scale traffic cannot be handled by a single server.

                   Users
                     │
                     ▼
               Load Balancer
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
      Server       Server       Server
        │            │            │
        └────────────┼────────────┘
                     ▼
              Distributed Services

We need horizontal scaling.

---

4. Consistency or Availability?

This is the most important Amazon interview discussion.

Overall answer:

It depends on the subsystem.

Amazon is not simply "consistency everywhere" or "availability everywhere."

Product catalog/search

Prefer:

Availability

Slightly stale data may be acceptable.

Example:

Product price displayed
= ₹999

Actual price
= ₹1,009

This can potentially be tolerated for a short period depending on the business rules.

---

Inventory

Need stronger consistency.

Suppose:

Inventory = 1

Two users simultaneously purchase it:

User A ── Buy ──┐
                ├── Inventory = 1
User B ── Buy ──┘

We cannot successfully sell the same final unit twice.

Therefore inventory needs strong concurrency control.

---

Payment

Consistency is critical

We must avoid:

₹1,000 charged twice ❌

or:

Order confirmed
BUT
payment never captured ❌

Therefore:

Payment and order state prioritize correctness/consistency.

---

5. Functional Requirements

Core Features

1. Seller Product Upload

Seller should be able to:

• Create product

• Add description

• Add images

• Set price

• Set inventory

• Update product

Seller
  ↓
Product Service
  ↓
Product Database

---

2. Browse Product Catalog

Customers should be able to:

• Browse categories

• View products

• View prices

• View availability

• View images

• View ratings

---

3. Search

Search by:

• Product name

• Brand

• Category

• Keywords

• Attributes

Example:

"wireless headphones"
        ↓
Search Service
        ↓
Search Engine
        ↓
Relevant Products

---

4. Shopping Cart ⭐

Customer can:

Add item
Remove item
Change quantity
View cart

Example:

Cart
 ├── iPhone × 1
 ├── Headphones × 2
 └── Charger × 1

---

5. Wishlist

Customer can save products for later.

---

6. Checkout

Checkout includes:

Cart
 ↓
Address
 ↓
Shipping option
 ↓
Inventory validation
 ↓
Price validation
 ↓
Payment
 ↓
Order creation

---

7. Payment

Support:

• Cards

• UPI

• Wallets

• Net banking

• Other payment methods

Critical requirement:

Payment must be idempotent.

---

8. Order History

Customer can see:

Order
 ├── Order ID
 ├── Items
 ├── Amount
 ├── Payment status
 ├── Shipping status
 └── Delivery date

---

9. ETA / Delivery Estimate

System should estimate:

"Expected delivery: September 2"

This can depend on:

• Warehouse

• Seller location

• Customer location

• Carrier

• Inventory availability

• Shipping method

---

6. Non-Functional Requirements

① High Availability ⭐⭐⭐

The marketplace should remain available even during:

• Black Friday

• Prime Day

• Festival sales

• Product launches

Because:

Downtime
   ↓
Lost customers
   ↓
Lost orders
   ↓
Lost revenue

---

② Low Latency

Typical operations should respond quickly:

Search       → low latency
Product page → low latency
Cart         → low latency
Checkout     → low latency

Especially during traffic spikes.

---

③ Scalability ⭐⭐⭐

The architecture must scale horizontally.

1M users
   ↓
10M users
   ↓
100M users

without redesigning the entire system.

---

④ Consistency

Particularly important for:

• Inventory

• Orders

• Payment

• Refunds

---

⑤ Reliability

The system must recover from:

• Server failure

• Database failure

• Network failure

• Service failure

• Payment provider failure

---

7. Scope Questions

Before architecture, ask these.

User scale

How many Daily Active Users?

---

Peak traffic

What is the peak load during Black Friday or Prime Day?

This is extremely important.

---

Conversion rate

How many users actually purchase something?

For example:

100M users browse
      ↓
10M add to cart
      ↓
2M purchase

---

Average order size

How many items are there per order?

For example:

Average = 3 items/order

This impacts:

• Inventory writes

• Order storage

• Checkout processing

---

Read/write ratio

Expected:

Reads >>> Writes

---

Replication factor

Ask:

How many replicas do we maintain?

Example:

Replication factor = 3

---

8. High-Level Architecture ⭐⭐⭐

This is the first diagram I would draw in an interview.

                         ┌──────────┐
                         │  Users   │
                         └────┬─────┘
                              │
                              ▼
                       ┌─────────────┐
                       │ API Gateway │
                       └──────┬──────┘
                              │
          ┌───────────────────┼────────────────────┐
          │                   │                    │
          ▼                   ▼                    ▼
   Product Service      Search Service       Cart Service
          │                   │                    │
          ▼                   ▼                    ▼
    Product DB         Elasticsearch           Cart DB
          │
          ▼
        Redis

          ┌─────────────────────────────────────┐
          │                                     │
          ▼                                     ▼
   Inventory Service                     Order Service
          │                                     │
          ▼                                     ▼
   Inventory DB                          Order Database
                                                │
                                                ▼
                                        Payment Service
                                                │
                                                ▼
                                       Payment Provider

Then add asynchronous processing:

                    Order Service
                         │
                         ▼
                       Kafka
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
      Inventory      Notification     Shipping
        Update         Service         Service

---

9. Microservices

At Amazon scale, separate services by business domain.

Product Service
Search Service
Inventory Service
Cart Service
Order Service
Payment Service
Shipping Service
User Service
Recommendation Service
Notification Service

This follows Domain-Driven Design.

Each service owns its business logic and preferably its data.

---

10. Product Catalog Architecture

Product information is highly read-heavy.

User
 ↓
Product Service
 ↓
Redis Cache
 ↓
Product DB

Cache hit

User
 ↓
Redis
 ↓
Product

Cache miss

User
 ↓
Redis ❌
 ↓
Product DB
 ↓
Redis ← Cache
 ↓
User

This significantly reduces database load.

---

11. Search Architecture

Use Elasticsearch/OpenSearch-style search infrastructure.

             Product DB
                 │
                 │ Change Event
                 ▼
               Kafka
                 │
                 ▼
          Search Indexer
                 │
                 ▼
          Elasticsearch
                 ▲
                 │
              Search
                 │
                User

Important concept:

Database is the source of truth.

Search index is a derived/read model.

Therefore:

Product DB
    │
    ▼
Search Index

can be eventually consistent.

---

12. Shopping Cart Design ⭐

Cart has unique access patterns.

A user frequently updates:

Add item
Remove item
Change quantity

Redis can be useful for fast cart operations.

Example:

Redis

user123
   ↓
cart
 ├── productA : 2
 ├── productB : 1
 └── productC : 3

But don't blindly treat Redis as the only durable source if cart persistence is a requirement.

Possible architecture:

Cart API
   │
   ├── Redis → fast access
   │
   └── Durable DB → persistence

---

13. Inventory — Most Important Deep Dive ⭐⭐⭐

Suppose:

Product X
Inventory = 1

Two users purchase simultaneously.

Bad implementation

User A reads = 1
User B reads = 1

A → purchase
B → purchase

Inventory = -1 ❌

We need concurrency control.

Possible solution:

Atomic conditional update

UPDATE inventory
SET quantity = quantity - 1
WHERE product_id = ?
AND quantity > 0;

Then check affected rows.

affected rows = 1 → purchase succeeds
affected rows = 0 → out of stock

This is a very good interview answer.

---

14. Inventory Reservation

During checkout:

Cart
 ↓
Reserve Inventory
 ↓
Payment
 ↓
Create Order

But what if payment fails?

Inventory should be released.

Reserve
   ↓
Payment
   │
   ├── Success → Confirm
   │
   └── Failure → Release

Reservation can have a TTL.

Example:

Inventory Reservation
expires after X minutes

This prevents inventory from being locked forever.

---

15. Checkout Saga ⭐⭐⭐

Checkout crosses multiple services:

Cart
 ↓
Inventory
 ↓
Payment
 ↓
Order
 ↓
Shipping

A distributed transaction across all services is usually undesirable.

Instead, use a Saga / workflow.

Example:

Start Checkout
      │
      ▼
Reserve Inventory
      │
      ▼
Authorize Payment
      │
      ▼
Create Order
      │
      ▼
Confirm Inventory

Failure:

Payment FAILED
      │
      ▼
Release Inventory
      │
      ▼
Checkout FAILED

This is a very strong system-design discussion.

---

16. Payment Idempotency ⭐⭐⭐

Imagine:

Customer clicks Pay
       ↓
Payment succeeds
       ↓
Network timeout
       ↓
Customer retries

Without idempotency:

₹1,000
+
₹1,000
=
₹2,000 charged ❌

Use an idempotency key.

payment_request_id = ABC123

If the same request arrives again:

ABC123
 ↓
Already processed
 ↓
Return previous result

Therefore:

Retry must not create a second payment.

---

17. Order State Machine

An order should have explicit states.

CREATED
   ↓
PAYMENT_PENDING
   ↓
PAYMENT_SUCCESS
   ↓
CONFIRMED
   ↓
SHIPPED
   ↓
OUT_FOR_DELIVERY
   ↓
DELIVERED

Failure paths:

PAYMENT_FAILED
CANCELLED
REFUNDED
RETURNED

This makes distributed order processing much easier to reason about.

---

18. Kafka / Event-Driven Architecture

After an order is created, many independent systems need to react.

Instead of:

Order Service
   │
   ├── call Inventory
   ├── call Email
   ├── call Shipping
   ├── call Analytics
   └── call Recommendation

which creates tight coupling:

Use Kafka.

                 Order Service
                      │
                      ▼
                  Kafka Topic
                      │
        ┌─────────────┼──────────────┐
        ▼             ▼              ▼
   Inventory      Notification    Analytics
     Consumer        Consumer       Consumer

Advantages:

• Loose coupling

• Async processing

• Better scalability

• Retry capability

• Consumer independence

---

19. Black Friday Architecture ⭐⭐⭐

This is probably the most important scalability discussion.

Normal day:

100K requests/sec

Black Friday:

5M requests/sec

Architecture must absorb the spike.

Techniques

Horizontal scaling

          Load Balancer
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
      API     API     API

CDN

Cache:

• Product images

• Static assets

• Public product information

Redis

Cache:

• Product metadata

• Prices where appropriate

• Popular products

• Categories

Queue

Use Kafka/queues to absorb asynchronous workloads.

Huge traffic
    ↓
Queue
    ↓
Workers process gradually

---

20. Thundering Herd Problem

Suppose a very popular product suddenly goes viral.

Millions request:

Product X

If cache expires at the same time:

Millions
   ↓
Redis MISS
   ↓
Database
   ↓
💥

Solutions:

• Cache warming

• Randomized TTL

• Request coalescing/single-flight

• CDN

• Replicas

• Rate limiting

---

21. Database Architecture

Don't use one giant database for everything.

Instead:

Product DB
Inventory DB
Order DB
Payment DB
Cart DB
User DB

This allows each domain to scale independently.

---

22. Read Replicas

For read-heavy data:

                 Primary
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       Replica    Replica    Replica
          │         │         │
         READ      READ      READ

Writes go to primary.

Reads can be distributed.

---

23. Database Sharding

At very large scale, partition data.

Example:

User ID
   ↓
Hash
   ↓
Shard

Shard 1 → Users 0–...
Shard 2 → Users ...
Shard 3 → Users ...

For orders, a natural partition key might be:

customer_id

or another access-pattern-driven key.

Be careful with hotspots.

---

24. CDN

CDN is especially useful for:

• Product images

• Static content

• Public assets

• Potentially cacheable product content

Example:

User
 ↓
CDN
 ↓
Product Image

No need to hit the origin every time.

---

25. Multi-Region Architecture

For global users:

                Global DNS
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
       US          EU          Asia
      Region      Region      Region

Benefits:

• Lower latency

• Disaster recovery

• Regional traffic isolation

• Better availability

But global consistency becomes more difficult.

---

26. CAP Theorem — Amazon ⭐⭐⭐

A strong interview answer:

"Amazon uses different consistency models for different domains. Product browsing and search can tolerate eventual consistency because availability and low latency are more important. Inventory, order processing, and especially payment require stronger consistency and concurrency control because incorrect state can result in overselling or financial errors."

Remember:

Catalog/Search
     ↓
Availability + Eventual Consistency

Inventory/Order/Payment
     ↓
Correctness + Stronger Consistency

---

27. Reliability & Failure Handling

Imagine Payment Service is down.

Don't lose the order state.

Use:

• Retry

• Exponential backoff

• Circuit breaker

• Idempotency

• Dead-letter queue

• Transactional/outbox patterns where appropriate

• Saga/workflow

• Monitoring

Example:

Payment Service
      ↓
     FAIL
      ↓
Retry
      ↓
Retry
      ↓
Circuit Breaker
      ↓
Graceful failure

---

28. Observability

Monitor:

API

• Request rate

• Latency

• Error rate

Database

• CPU

• Connections

• Query latency

• Replication lag

Kafka

• Consumer lag

• Throughput

• Failed messages

Business

• Checkout success rate

• Payment success rate

• Cart abandonment

• Order creation rate

• Inventory mismatch

---

29. Security

Important areas:

Authentication
Authorization
Encryption
Payment security
Fraud detection
Rate limiting

Never store raw card information unless the system is specifically designed and certified to do so.

Prefer integration with a payment provider/tokenization mechanism.

---

30. Amazon vs Spotify — Important Interview Comparison

Since you're studying system design sequentially, remember this difference:

Aspect	Spotify	Amazon
Primary workload	Streaming	E-commerce
Traffic	Read-heavy	Read-heavy
Main data	Audio	Product/order data
Storage	Object storage	DB + object storage
CDN	⭐⭐⭐	⭐⭐⭐
Search	Elasticsearch	Elasticsearch
Kafka	Events/recommendations	Orders/events
Availability	⭐⭐⭐	⭐⭐⭐
Consistency	Generally less critical	Critical for inventory/payment
Main challenge	Smooth streaming	Correct checkout + huge spikes
Key deep dive	CDN/audio chunks	Inventory + payment + order

---

🎯 31. The Amazon Architecture You Should Memorize

                         USERS
                           │
                           ▼
                    ┌─────────────┐
                    │ CDN / WAF   │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ API Gateway │
                    └──────┬──────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
        ▼                  ▼                  ▼
   Product Service    Search Service      Cart Service
        │                  │                  │
        ▼                  ▼                  ▼
      Redis          Elasticsearch         Redis/DB
        │
        ▼
   Product DB

        ┌───────────────────────────────────────┐
        │                                       │
        ▼                                       ▼
 Inventory Service                         Order Service
        │                                       │
        ▼                                       ▼
 Inventory DB                              Order DB
                                                │
                                                ▼
                                         Payment Service
                                                │
                                                ▼
                                        Payment Provider

                         Order Events
                              │
                              ▼
                            Kafka
                              │
             ┌────────────────┼─────────────────┐
             ▼                ▼                 ▼
        Inventory       Notification        Shipping
        Consumer           Consumer          Consumer
                              │
                              ▼
                         Analytics /
                       Recommendation

---

🧠 32. 30-Second Interview Answer

If the interviewer asks:

"Give me the high-level design for Amazon."

Say:

"I would design Amazon as a distributed, highly scalable, read-heavy e-commerce platform using domain-based services such as Product, Search, Cart, Inventory, Order and Payment. Product and search data can use caching, read replicas and eventual consistency for high availability and low latency. Checkout is different: inventory, orders and payments require stronger consistency, idempotency and concurrency control to prevent overselling and duplicate charges. I'd use Redis for hot data, Elasticsearch for search, durable databases for transactional data, object storage and CDN for product media, and Kafka for asynchronous order, notification, shipping and analytics workflows. Finally, I'd use horizontal scaling, multi-region deployment, rate limiting and queues to survive Black Friday-scale traffic spikes."

⭐ Most important concepts to remember

Amazon System Design =

Catalog + Search + Cart + Inventory + Order + Payment + Kafka + Scaling

And the single most important interview distinction:

"Availability for browsing; consistency for money and inventory."