Design a Bookstore Pricing API with Batch Fetches
DatabricksSoftware Engineer · OnsiteLast updated
Tests system design skills for building a high-throughput, contextual pricing service that balances HTTP protocol semantics, batch orchestration, personalized caching, and downstream protection.
Scenario
Design the core Pricing Service for an international online bookstore platform. The service serves product detail pages, checkout funnels, search result listings, and partner book aggregators. A single search result page or recommendation carousel may request real-time pricing for up to 100 books at once.
Prices are dynamic and depend on contextual factors such as customer loyalty tier, delivery country, applied discount codes, and active flash sales.
Requirements
Functional Requirements
- Item & Batch Fetching: Support price retrieval for a single book or batches of up to 250 books per request.
- Pricing Context: Accept pricing context (e.g., user loyalty level, shipping destination country, promo tokens, currency).
- Explicit Freshness: Every returned price must explicitly indicate its calculation timestamp, guaranteed validity window (TTL), and whether it was served from cache or computed fresh.
- Partial Failure Handling: In a batch lookup, failures to resolve specific items (e.g., unlisted book ID, timeout from a regional tax module) must return item-level errors without failing the entire batch.
Non-Functional Requirements
- Throughput: 100,000 requests per second at peak, averaging 10 books per request (1,000,000 item evaluations/sec).
- Latency: Single-item p99 < 25 ms; 100-item batch p99 < 75 ms.
- Catalog Scale: 50 million active titles across 30 regional markets.
- Availability: 99.99% for pricing evaluations.
Key Design Discussion Areas
- API Protocol & Contract: Contrast HTTP
GETwith query parameters versus read-onlyPOSTfor large batch requests (considering URL length limits, intermediate proxy caching, and idempotency). Define the JSON request/response schema with per-item status envelopes. - Batch Orchestration & Fan-Out: Detail internal handling of batch requests—request deduplication (e.g., same book requested multiple times in one batch), batch decomposition, bounded concurrency, and deadline propagation to downstream services (base catalog, dynamic promotion engine, tax engine).
- Contextual Caching: Design a caching topology that handles user personalization without collapsing cache hit ratios. Consider two-tier caching, segment-based cache keys, and cache stampede protection (
stale-while-revalidate, single-flight mutexes). - Overload Control & Fault Tolerance: Address backpressure, circuit breaking, degraded fallback modes (e.g., serving stale prices marked as unverified for browse traffic vs. strictly blocking stale prices for checkout), and client-side retry amplification.
Hints
Hint 1
Consider how standard HTTP proxies handle caching for `GET` versus `POST` requests and explore techniques like deterministic query param sorting or custom caching gateways if using `POST`.
Hint 2
Decouple static pricing inputs (base MSRP, publisher constraints) from volatile contextual inputs (promotions, user tiers) to maximize cache hit rates across disparate users.
Hint 3
Use a per-item response envelope that pairs item IDs with either a pricing payload or a structured error code, ensuring downstream timeouts on a single SKU do not cascade into HTTP 500s for the whole request.
Follow-up questions
- How would you prevent a client from causing downstream resource exhaustion by submitting a batch containing 250 distinct IDs that all miss the cache simultaneously?
- If checkout requires strict transactional accuracy while search browse pages tolerate slight staleness, how do you adapt your freshness contracts and routing for each caller?
- How do you implement distributed tracing and request-deadline propagation when fan-out sub-queries to promotion microservices are executed asynchronously?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.