Design Amazon

Amazon pioneered the "two-pizza team" rule: each service is owned by a team small enough to be fed by two pizzas. Services: Catalog (product data), Cart (session state), Order (order lifecycle), Payment (transaction processing), Inventory (stock levels), Fulfillment (warehouse routing), Notification (email/SMS). Each service has its own database (Database-per-Service pattern) — a Catalog search slowdown cannot cascade to block Order processing.

The shopping cart is a key-value store naturally: key = user_id, value = {list of items, quantities, prices}. DynamoDB is ideal: O(1) get/put by user_id, extremely low read/write latency (< 5ms), scales to millions of writes/sec, and handles Black Friday spikes without configuration changes (on-demand capacity mode). SQL databases would require complex sharding for this access pattern.

In a monolith, order checkout is one database transaction (ACID). In microservices, it spans 5 services — you cannot use 2-Phase Commit (2PC) because it locks resources across services and one slow service blocks everything. The Saga pattern breaks the transaction into a sequence of local transactions, each publishing an event. If any step fails, compensating transactions undo the previous steps.

Payment processing must be exactly-once — double-charging a customer is a severe business and legal problem. If a network timeout occurs after the payment succeeds but before the response returns, the client may retry — causing a second charge. Solution: the client generates a unique idempotency_key (UUID) per checkout attempt. The Payment Service stores {idempotency_key → result} in Redis. On retry with the same key: return the cached result, don't re-charge.

Pessimistic locking: Lock the inventory row when a user adds to cart. No other user can buy the same last item. Problem: locks are held for seconds during checkout — massive contention at scale. Optimistic locking: Allow multiple users to proceed; check stock at payment time. Use a version number: SELECT stock, version WHERE product_id = X → UPDATE stock = stock-1 WHERE version = {saved_version} → if update changes 0 rows, another user bought it first (conflict). Retry or show "out of stock."

Product catalog has 350M+ items with rich attributes (name, brand, category, specs, price, ratings). SQL LIKE queries are too slow for full-text search at this scale. Elasticsearch provides: full-text search with relevance ranking, faceted filtering (category, price range, rating), autocomplete suggestions, and near-realtime index updates. Product metadata is asynchronously synced from PostgreSQL to Elasticsearch after any update.