Design a Book Purchase Broker

Scenario Design a system that accepts a user's request to buy a book by title, ISBN, or another identifier. The request includes a maximum target price and an expiration time. The system should query a limited set of partner bookstores, find available inventory, and place an order if the best available price is at or below the user's target price before the request expires. If no store can satisfy the price constraint, return the best available price to the user. If no store has inventory, notify the user that the book is unavailable. Requirements - Support creating, checking, and canceling purchase requests. - Query multiple partner bookstores asynchronously. - Compare total prices, including taxes, fees, and shipping when available. - Place at most one order for each user request. - Respect request expiration times. - Handle partner timeouts, retries, duplicate callbacks, partial failures, and changing inventory. - Notify users about ordered, quoted, out-of-stock, expired, and failed outcomes. Clarifying Questions - Is the target price based on item price only, or total landed cost including shipping and tax? - Can a request be partially fulfilled, such as used versus new copies, or does it require an exact edition? - How many partner bookstores are queried per request, and what latency SLA should the user see? - Are partner APIs synchronous, asynchronous callback-based, or a mix of both? - Should the system reserve inventory before charging the user, or authorize payment first and then place the order? What a Strong Answer Covers - Clear APIs for request creation, status lookup, cancellation, and partner callback handling. - A durable state machine for request lifecycle: pending, searching, quoted, ordering, ordered, expired, out_of_stock, failed, and canceled. - Asynchronous fan-out to partner bookstores through queues or workflow orchestration. - Idempotency for request creation, partner quote ingestion, payment authorization, and order placement. - Timeout and expiration handling so stale partner responses cannot trigger late orders. - Price comparison logic based on total cost and inventory availability. - Failure handling with retries, circuit breakers, dead-letter queues, and reconciliation jobs. - Observability for partner latency, queue lag, order success rate, quote rate, timeout rate, and user-visible SLA. Follow-up Questions - How would you prevent two workers from ordering the same book for one request? - How would you handle a partner that confirms inventory but fails during order placement? - How would the design change if there were thousands of partner stores instead of a limited set? - How would you support request updates, such as increasing the target price before expiration? - What consistency guarantees are required between payment authorization, partner ordering, and user notification? Hints - Treat partner calls as unreliable external dependencies and isolate them behind queues and per-partner rate limits. - Model the purchase request as a state machine and guard every transition with idempotency keys. - Separate quote collection from order placement so the system can safely compare prices before committing.