Designing the Core API Endpoints Behind Amazon's Shopping Experience

Amazon.com's website and mobile apps load data and take actions through backend APIs. What are some of the endpoints you would expect Amazon.com to have? ```hint Follow one purchase Trace a shopper from searching for a product to receiving it, and at each step ask what the app has to fetch and what it has to change. ``` ### Clarifying Questions - Do you mean the endpoints the Amazon.com web and mobile clients call, or the public APIs Amazon offers to sellers and partners? - Should I cover only the shopper side, or also sellers listing products and the delivery side? - How much detail do you want per endpoint: just the method and resource, or also the request, response and error cases for an important one? ### What a Strong Answer Covers - Endpoints organized around the shopper journey or its domains (account, search and catalog, cart, checkout, orders and returns), not a random list - Correct use of HTTP methods, resource paths and identifiers, plus authentication and pagination - Depth on at least one critical write, such as placing an order: inputs, outputs, idempotency and failure cases - Which calls are read-heavy and cacheable versus which writes must be strongly consistent, and why price and stock are treated differently from product descriptions - How endpoint choices connect to product decisions a PM would own ### Follow-up Questions - The place-order call times out and the shopper taps the button again. How do you make sure they are not charged twice? - Which of these endpoints would you cache, and what goes wrong if the cached data is stale? - Product wants a delivery-date estimate on every search result. Which endpoints change, and what does that cost?