1. The Headline

Serving billions of pageviews on Prime Day with 100% uptime.

Amazon's architecture defined the modern microservices movement. During peak events like Black Friday or Prime Day, a single popular product page might be requested tens of thousands of times a second. If the page takes longer than 1 second to load, revenue demonstrably drops.

2. Requirements and Constraints

Functional Requirements:

• View product details, reviews, and related items.
• Personalization: "Hello Amit, recommendations for you."
• Add items to the cart instantly and accurately.

Non-Functional Requirements:

• Extreme Availability: The site cannot go down, even if the recommendation engine crashes.
• Speed: Time-to-Interactive (TTI) must be minimal.
• Consistency: The shopping cart is a financial transaction; it must be strictly consistent.

The Ultimate Constraint: A product page contains both static data (the product title, the images) and highly dynamic data (your personal cart count, the current price in your currency, your prime status). You cannot cache a page that says "Hello Amit" and serve it to Bob. But if you dynamically render the entire page from scratch for every user, the backend servers will melt under Prime Day traffic.

3. The Naive Design & Where It Breaks

A naive approach to an e-commerce product page:

• User requests /product/123.
• The Node.js/Java server fetches the product details, reviews, and the user's cart from PostgreSQL.
• The server stitches everything into an HTML template and sends it to the user.

Where this breaks:

1. CPU Exhaustion: Server-Side Rendering (SSR) millions of pages a minute requires a massive, expensive server farm.
2. Database Locks: If a product goes viral, 10,000 users reading the same database row simultaneously will create extreme read contention.
3. The Single Point of Failure: If the "Related Products" microservice goes down, the entire page fails to render, preventing the user from buying the main product.

4. The Real Architecture: Layer by Layer

Edge Caching and "Hole Punching"#

Amazon solves the static/dynamic problem at the CDN edge (CloudFront).

• The "shell" of the product page (images, description, title) is heavily cached at the CDN. It is identical for everyone in the world.
• When you request a page, the CDN serves the cached HTML instantly.
• Included in that HTML are empty <div> containers (holes).
• Once the HTML loads in your browser, the frontend executes small, isolated JavaScript bundles that fetch the dynamic data (your cart count, your name) directly from the API and punch them into the holes.

Micro-Frontends (Islands Architecture)#

The Amazon product page is not a single React application. It is composed of dozens of independent Micro-Frontends.

• Team A builds the "Buy Box."
• Team B builds the "Customer Reviews."
• Team C builds "Related Items." If Team C's backend service crashes, the Related Items section on the frontend simply collapses or shows a fallback, but the Buy Box continues to function perfectly. The user can still check out.

The Shopping Cart (DynamoDB)#

While the product catalog is heavily cached, the Shopping Cart cannot be. The Cart requires high availability and strict durability. Amazon built DynamoDB specifically to handle this use case—a NoSQL database designed for single-digit millisecond latency at any scale, ensuring that if you add an item to your cart, it is never lost, even if a server rack explodes.

5. The Hard Problem

Inventory consistency during flash sales.

If Amazon has 10 PlayStations in stock and 100,000 people hit "Add to Cart" at the exact same second, how do you prevent overselling without locking the database (which would bring the site to a halt)?

6. What This Means for the Client (Frontend)

The frontend client must mask backend inventory contention using Optimistic UI and asynchronous flows.

Optimistic Add-to-Cart#

When you click "Add to Cart", the frontend does not wait for the database to lock the inventory row.

1. The frontend instantly animates the item flying into your cart icon and increments the counter from 1 to 2.
2. It fires a non-blocking API request to the backend.
3. The backend puts the request in a high-speed Queue (like SQS).
4. A worker processes the queue and attempts to secure the inventory.
5. If the inventory is gone, the frontend receives a WebSocket/Polling update later, adjusting the cart and displaying a polite notification: "Sorry, this item just sold out."

By decoupling the button click from the actual database transaction, the frontend feels blazingly fast and the backend is protected from traffic spikes.

Partial Hydration#

Amazon does not use a massive Single Page Application (SPA) architecture because downloading a 5MB JavaScript bundle on a 3G connection would kill conversions. The page relies heavily on vanilla HTML/CSS. JavaScript is only downloaded and executed (hydrated) for the specific interactive widgets (the Buy Box, the image carousel) using techniques similar to modern Astro or React Server Components.

7. Failure Modes & Graceful Degradation

• Recommendation Engine Outage: The frontend wraps the recommendations component in an Error Boundary. If it times out, the space is hidden via CSS, leaving a clean page.
• Image CDN Degradation: The frontend always specifies explicit width and height attributes on images. If the images load slowly, the page layout does not jump around (Cumulative Layout Shift), preserving the reading experience.

8. Numbers & Tradeoffs

• Architecture: CDN edge caching, Micro-Frontends, asynchronous queues.
• Tradeoff: By making the "Add to Cart" action asynchronous, Amazon accepts a tiny percentage of "oversell" apologies in exchange for 100% availability and zero-latency UI interaction for millions of users.

9. How to Use This in an Interview

If an interviewer asks you to design an e-commerce platform or a high-traffic media site:

"To survive massive traffic spikes, we cannot server-side render personalized pages for every request. We must separate static and dynamic data. We should cache the static HTML shell at the CDN edge. The frontend will then fetch personalized data (like cart state) client-side and inject it into the page."

"To prevent database deadlocks during flash sales, the 'Add to Cart' action should be asynchronous. The frontend will optimistic-render the success state while the backend processes the transaction through a message queue."

10. Sources

• Amazon's Distributed Computing Manifesto (1998)
  https://www.allthingsdistributed.com/2022/11/amazon-1998-distributed-computing-manifesto.html
• Dynamo: Amazon’s Highly Available Key-value Store
  https://www.allthingsdistributed.com/2007/10/amazon_dynamo.html