Hello Interview · Four community designs · Cross-source overview

Book Seller Marketplace

Accept a buyer's ISBN and maximum price, identify an eligible seller, reserve inventory, coordinate payment, and complete exactly one purchase despite retries and third-party failures.

Peak10K queries/s
Sources4 implementations
SelectionLowest price ≤ maximum
Hard invariantOne winner, one charge

Problem statement

Customers submit purchase requests containing customer information, a book identifier, a maximum acceptable price, and payment information. Registered sellers expose different APIs. The platform finds the lowest eligible offer and initiates a purchase while supporting synchronous and asynchronous processing at up to 10,000 queries per second.

Tier 1 · Common architecture

  1. Register sellers: store endpoints, authentication metadata, capabilities, and rate limits.
  2. Accept and persist: validate an idempotency key, create the order, and make it durable before fulfillment.
  3. Dispatch asynchronously: queue or workflow workers isolate the request path from seller latency.
  4. Choose candidates: query sellers live or consult a maintained price and inventory index.
  5. Reserve inventory: create a seller hold with an expiry before final payment.
  6. Complete one attempt: authorize, confirm, capture, and reconcile through explicit states.

Minimal interfaces

POST /sellers → seller_idPOST /orders { isbn, max_price, payment_method_token } → order_idGET /orders/{order_id} → status, seller, priceseller: quote · hold · confirm · release

Shared data model

  • seller(id, endpoints, auth_ref, rate_limit, status)
  • order(id, user_id, isbn, max_price, status, winner_seller_id)
  • hold(id, order_id, seller_id, held_price, expires_at, status)
  • payment(id, order_id, provider_ref, amount, status)
  • Optional internal offer record: (isbn, seller_id, price, availability, freshness)

Design center

DurabilityAn accepted request survives process and queue failures. A transactional outbox or a pending-order scanner closes the DB-to-queue gap.
Single winnerA DB compare-and-set or one durable workflow owns the transition into the commit phase.
InventoryThe seller hold is the cross-system reservation boundary. It carries price, expiry, and an idempotency key.
PaymentsCard data is tokenized by the payment processor. Authorization, capture, refund, and reconciliation have distinct states.
PolitenessSeller-specific concurrency limits, token buckets, timeouts, backoff, and circuit breakers protect external APIs.

Recall test

  1. Which durable operation happens before fulfillment begins?
  2. Where is the winning seller committed atomically?
  3. Why is a seller hold stronger than cached availability?
  4. Which payment event moves money?
  5. How does the workflow recover from duplicate queue delivery?