Design a Book Seller Platform
Design a service where customers can submit book purchase requests with details such as customer information, book info, maximum price willing to pay, and payment information. The service should check with registered book sellers to find books priced at or below the maximum price. It should place a buy request with the seller offering the minimum price within the customer's limit. The design should include APIs for book seller registration and adapt to various seller APIs, supporting up to 10,000 queries per second.
Asked at:
Databricks
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to submit a book buy request with book details, a maximum price, and payment authorization.
Users should be able to automatically purchase from the seller offering the lowest available price at or below their maximum price.
Users should be able to track the status of their request and receive a final confirmation or failure with a clear reason.
Sellers should be able to register on the platform, configure credentials/endpoints, and validate connectivity for quotes and order placement.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
Tips: Discuss a hybrid of synchronous quick answers and asynchronous completion: set a strict per-seller timeout and a global SLA, fan out requests in parallel with concurrency limits, and return the best-so-far result or a job ID if still running. Use caching (short TTL per ISBN + seller), batching where supported, circuit breakers, and per-seller rate limits. Consider prefetching/populating a price cache from periodic updates or streams when sellers support it.
Tips: Treat cache prices as hints and re-validate with the seller before committing. Implement a two-step flow: (1) soft-reserve/hold at seller with the quoted price, (2) capture payment only after hold succeeds. If multiple sellers compete, place holds in ascending price order with timeouts. Use ETags/versioning for quotes and reject if the price changed. Clearly define consistency and the acceptable staleness window.
Tips: Model it as a saga: authorize payment (not capture), reserve with seller, capture payment, finalize order; on failures, compensate (release hold, void authorization, issue refund). Use idempotency keys for client requests, retries with deduplication, and outbox/transactional messaging to avoid double charges or orphaned holds. Persist workflow state to resume after crashes.
Tips: Define a normalized Seller Adapter interface (quote, reserve, purchase, cancel) and build per-seller connectors that translate protocols/auth, handle retries/backoff, and map errors. Provide a self-serve seller onboarding API/portal with schema validation, sandbox testing, and health checks. Use webhooks or feeds when available to ingest inventory/price changes; otherwise rely on polling with adaptive intervals and backoff. Isolate bad sellers with circuit breakers and quarantine.
Relevant Patterns
Relevant patterns that you should know for this question
Buying is a multi-step workflow across external systems: quote, reserve/hold, payment capture, and confirmation. A saga with compensation handles partial failures, retries, and idempotency to prevent double charges or leaked reservations.
Fanning out to many sellers plus payment steps can exceed a tight synchronous SLA. Offloading to a job queue with callbacks/polling avoids client timeouts, smooths bursts to meet 10k QPS, and enables durable progress and retries.
Popular titles can cause many buyers to compete for limited stock at the lowest price. You need reservation semantics, short holds with TTL, idempotency, and concurrency control to avoid double-selling and ensure fairness.
Relevant Technologies
Relevant technologies that could be used to solve this question
PostgreSQL offers strong consistency for orders, payments, and workflow state. It supports transactions, unique constraints for idempotency, and can scale reads via replicas while keeping write integrity for financial records.
Similar Problems to Practice
Related problems to practice for this question
Both require reserving scarce inventory under heavy contention and confirming purchases without double-selling. Reservation holds, timeouts, and atomic purchase flows are central to both designs.
You must handle authorization vs capture, idempotency keys, retries, and compensations (voids/refunds). The financial correctness and PCI-aware flow mirror a payment processor’s concerns.
Selecting the best (lowest) price and dealing with rapidly changing availability/prices across sellers resembles bidding dynamics, with consistency, fairness, and race conditions to manage.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Designing the entire flow as a single synchronous request waiting on all sellers
This causes high tail latency, timeout cascades, and poor availability under load. It will not scale to 10k QPS and makes the system brittle to slow or failing sellers.
No reservation/hold step with the seller before capturing payment
Capturing payment without a confirmed hold risks double-selling or charging customers for out-of-stock items, creating refunds, churn, and trust damage.
Ignoring idempotency, retries, and isolation from flaky seller APIs
Without idempotency keys, deduplication, circuit breakers, and rate limits, transient failures lead to duplicate orders/charges and cascading outages across the integration surface.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late August, 2025
Databricks
Senior
Late July, 2025
Databricks
Senior
Late July, 2025
Databricks
Manager
Your account is free and you can post anonymously if you choose.