## Design a Bookstore Pricing API with Batch Fetches In a high-level system-design discussion, design the HTTP interface and supporting service for fetching book prices. Explain when the API should use `GET` and when a `POST` endpoint is justified, then design an efficient way to fetch prices for a batch of books. The original prompt does not provide traffic, catalog size, price dimensions, or freshness requirements. State those assumptions instead of treating them as known interview facts. ### Part 1 — Define the Pricing Contract Clarify what identifies a book, which context can change its price, and what the caller needs from a single-price and batch-price response. #### What This Part Should Cover - Stable book identifiers and any market, currency, customer, or edition context that belongs in the request. - Whether the response represents a current quote, a cached display price, or a price valid for a stated interval. - Missing books, unavailable prices, and partial success in a batch. - Batch-size, payload-size, latency, and freshness expectations. ```hint Separate identity from price context Two requests for the same book identifier may not be equivalent if region, currency, customer eligibility, or quote time changes the result. ``` ### Part 2 — Choose Between GET and POST Propose concrete HTTP endpoints for one book and for a batch. Justify the method choice using HTTP semantics and operational behavior rather than a rule that reads are always `GET` or batches are always `POST`. #### What This Part Should Cover - Safety, idempotency, cacheability, observability, and retry behavior. - URL-length and structured-body constraints for large batches. - Stable request and response schemas, validation errors, and versioning. - Authentication, authorization, rate limits, and request identifiers. ```hint Start from the request shape The useful comparison is between a cache-friendly resource lookup and a potentially large, structured read request, not between “read” and “write” labels alone. ``` ### Part 3 — Execute Batch Price Fetches Efficiently Describe the service path from an accepted batch request to a complete response. Avoid turning one client batch into an uncontrolled series of downstream calls. #### What This Part Should Cover - Input deduplication while preserving a deterministic mapping back to requested items. - Bounded parallelism, downstream batching, deadlines, and cancellation. - Cache keys and invalidation or freshness behavior. - Per-item status and an explicit policy for partial downstream failure. ```hint Bound the fan-out A batch endpoint improves little if every item creates an independent, unbounded request to the same dependency. ``` ### Part 4 — Scale and Operate the Service Explain how the design handles hot books, large clients, dependency degradation, and price changes while remaining observable. #### What This Part Should Cover - Admission control, maximum batch sizes, backpressure, and fair use across callers. - Caching or read models appropriate to the declared freshness contract. - Timeouts, retries, circuit breaking, and protection against retry storms. - Metrics for latency, batch shape, cache behavior, partial failures, stale responses, and downstream load. ```hint Measure batches as distributions Average request latency alone will hide whether large batches, hot identifiers, or one downstream partition dominate the work. ``` ### What a Strong Answer Covers - Requirements that make price identity and freshness explicit. - A defensible `GET` versus `POST` decision grounded in HTTP behavior. - Bounded and deterministic batch execution rather than accidental N-plus-one fan-out. - Clear partial-failure semantics, overload controls, and operational signals. ### Follow-up Questions 1. Can a read-only `POST` endpoint still be idempotent, and how would clients retry it? 2. How would you preserve input order while deduplicating repeated book IDs internally? 3. What changes if prices are personalized and therefore unsafe for shared caches? 4. When should a batch return a mixed result instead of failing the whole request?