Design an e-commerce platform (Amazon / Flipkart)

An order touches services that cannot share one database transaction: inventory, payment, order, and later fulfilment. Use a saga: a sequence of local transactions with compensations. The order service owns a state machine: CREATED -> PENDING_PAYMENT -> CONFIRMED -> PACKED -> SHIPPED -> DELIVERED, with side branches CANCELLED, PAYMENT_FAILED, RETURN_REQUESTED, REFUNDED. Every transition is a conditional update (UPDATE ... WHERE id = ? AND status = 'PENDING_PAYMENT' AND version = ?), so two concurrent events cannot both win. Compensations: payment failed -> release reservation; reservation expired before payment -> cancel order and auto-refund any late payment; seller cannot fulfil -> cancel that item, refund, and offer an alternative seller. Orchestration (the order service or a Temporal workflow drives steps) is easier to reason about and debug for checkout than pure choreography. Every external call carries the order_id as an idempotency key, so retries after timeouts are safe. Finally, run a reconciliation job that compares orders with payment provider settlement reports every few hours to catch anything a lost webhook missed.

Mobile networks in India drop requests often. A user taps 'Pay', the request reaches the server, the response is lost, and the app retries. Without protection you get two orders and maybe two charges. Three layers stop this. First, the client creates an Idempotency-Key per checkout attempt and resends it on retry; the server stores (user_id, key) with a unique constraint and returns the stored response for repeats. Second, payment calls use order_id as the merchant reference so the payment provider rejects a second payment intent for the same order. Third, the webhook handler is idempotent: it records payment_id as processed and ignores duplicates, because providers deliver webhooks at least once. Also handle the case where the user gives up and retries with a new key: the app shows the existing pending order instead of creating a new one when the cart has not changed. Saying 'exactly-once delivery does not exist end to end; we make every step idempotent' is what interviewers want to hear.

Stock must never go below zero, but locking a row for the whole payment (which can take minutes with UPI) would kill throughput. So checkout reserves: a single atomic conditional update such as UPDATE inventory SET available = available - :qty, reserved = reserved + :qty WHERE sku_id = :sku AND warehouse_id = :wh AND available >= :qty. If zero rows change, the item is out of stock at that warehouse and the service tries the next nearest warehouse. A reservation row records order_id, quantity and expires_at. On payment success the reservation is committed (reserved decreases, the item is gone); on failure or expiry a sweeper releases it back to available. For a few extremely hot SKUs during sales, a single row becomes a hot spot; those are handled by the flash-sale design (Redis counters, token buckets, queues). Mention that 'add to cart' does not reserve stock: carts are wish lists, and reserving at cart time lets bots lock up inventory.

Split by business capability, each service owning its data: catalogue (listings, content), pricing and offers, inventory, cart, order, payment, fulfilment, user and address, seller. Do not let services read each other's tables; they call APIs or consume events. Reads that combine data (the product page, 'my orders' with tracking) are built by an aggregator or by read models fed from events, so the order service is not called with heavy joins for every page view. Consistency needs differ: money, order state and stock need strong consistency inside their owner; search, recommendations, review counts and analytics can lag by seconds or minutes. The transactional outbox keeps events and state changes atomic without two-phase commit. In an interview, do not draw 30 microservices; draw the 5-6 that matter for the order path and say the rest exist.

Orders need multi-row transactions (order, items, outbox), constraints (unique idempotency key) and flexible queries for support tools, so a relational DB sharded by user_id (or a distributed SQL like Vitess/TiDB) fits. Carts and sessions are simple key lookups, where Redis or DynamoDB is cheaper.

Orchestration puts the checkout logic in one place with clear state and timeouts, ideal for the critical path. Choreography (services react to events) is fine for side effects like emails, invoices and analytics, where no central decision is needed.

Reserving at add-to-cart lets carts hoard stock; reserving only after payment risks taking money for items that are gone. Reserve at checkout with a short TTL; refund automatically in the rare race.

A modular monolith is faster to build for a startup; at Flipkart scale independent scaling and deploys of catalogue, cart and order justify services. Mention the cost: distributed transactions and harder debugging.

20x spikes at fixed times. Pre-scale stateless services and database capacity, warm caches, put a virtual waiting room in front of checkout, and turn off non-essential features (recommendations, reviews) with flags to protect the order path.

A single phone launch can get 100k checkout attempts per second on one row. Move that SKU to a Redis-based counter with admission control; see the flash-sale design.

Shard by user_id; keep transactions small; move status-history writes and analytics to async consumers. Order lookup by order_id works because the ID encodes the shard.

Order stays PENDING_PAYMENT. A poller queries the payment service for orders pending more than a few minutes, and the reconciliation job checks settlement files. The reservation TTL is longer than the payment window to avoid cancelling a paid order.

Order state is already committed with an outbox row; events are published when the relay recovers. Downstream steps are delayed, not lost. Consumers are idempotent by event_id.

Checkout cannot safely reserve, so it fails fast with a clear message rather than overselling; browse and cart keep working. Circuit breakers stop retry storms.