Book Seller · Source-backed requirements
Requirements and Constraints
The prompt fixes the marketplace behavior and 10K-QPS target. The submissions add explicit correctness, security, latency, and seller-integration requirements that their architectures attempt to satisfy.
Functional requirements
- A seller can register its identity, supported endpoints, authentication method, and rate limit.
- A buyer submits customer details, ISBN or book information, maximum price, and a payment reference.
- The platform finds sellers offering the book at or below the maximum.
- The lowest eligible offer wins according to the prompt.
- The platform places a hold or buy request with the winning seller.
- The buyer can retrieve order status; several submissions return an order ID immediately.
- Seller APIs vary, so the integration layer translates endpoint shape, authentication, and failure behavior.
External seller contract
checkOffer(isbn) → price, availability, freshnesscreateHold(isbn, order_id, ttl, idem_key) → hold_id, held_price, expiryconfirmPurchase(hold_id, order_id, idem_key)releaseHold(hold_id, order_id, idem_key)The first staff submission names price, purchase-hold, and purchase-confirmation endpoints. Review threads add an explicit release operation and stable idempotency keys.
API surface
POST /sellersPOST /orders · Idempotency-Key: client-generatedGET /orders/{order_id}A reviewer corrected GET /orderStatus?orderId=… to the resource-shaped GET /orders/{id}.
Non-functional requirements
- Scale: serve up to 10,000 queries per second and absorb bursts.
- Correctness: prevent duplicate orders, double capture, and more than one winning seller.
- Durability: retain every accepted order across service, worker, and queue failures.
- Availability: continue when individual sellers are slow or unavailable.
- Politeness: respect each seller's rate limits and avoid redundant calls.
- Security: keep raw card data outside the platform; protect seller credentials and webhook authenticity.
- Latency: one submission targets fulfillment within 20 seconds; other submissions use asynchronous status polling.
Consistency boundaries
| State | Required behavior |
|---|---|
| Order intake | Durable before work dispatch; repeated client key returns the same order. |
| Winner selection | One atomic claim transitions the order into commit. |
| Inventory | Seller hold is authoritative; cached availability remains advisory. |
| Payment | Provider idempotency key and webhook reconciliation resolve ambiguous outcomes. |
| Catalog | Eventual consistency is acceptable when final reservation revalidates price and stock. |
What the sources leave open
- Whether sellers push inventory, the platform polls, or both modes coexist.
- Whether the platform owns authorization and capture or sellers settle directly.
- Whether fairness requires per-book ordering during scarce inventory events.
- How long price records remain valid before live revalidation.
- Which seller attributes break ties after price.
- How product policy handles late-arriving offers for an already pending request.