Katkat
Back

Design a Book Purchase Broker

Sentry.IoSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests the ability to design a resilient distributed system that orchestrates third-party API calls, handles partial failures, and ensures transactional integrity across asynchronous boundaries.

Problem: Book Purchase Broker

Design a service that acts as an intermediary for purchasing books from multiple partner bookstores. A client sends a request to buy a specific ISBN, specifying a maximum budget and a time-to-live (TTL) for the transaction.

Requirements:

  1. Fan-out: The system must check multiple partner bookstore APIs concurrently to find the best price.
  2. Selection Logic: If a bookstore offers the book at or below the target price before the TTL expires, the system must trigger an purchase.
  3. Idempotency: Partners might have unreliable networks; the system must ensure a book is not purchased twice if a request times out.
  4. Payment Handling: The system must coordinate payment capture with an internal payment service only after a bookstore confirms the order.

Functional Requirements:

  • POST /v1/purchase (Accepts ISBN, quantity, max_price, ttl_ms)
  • Must handle asynchronous status updates.
  • Must provide an endpoint to check the status of a pending order.

Non-Functional Requirements:

  • High availability for the entry point.
  • Fault tolerance: If one bookstore is down, others should still process the request.
  • Auditability: Maintain a history of price checks and partner responses for debugging.

Output

Describe your API design, database schema, and the workflow for orchestrating the request. Explain how you would manage the state machine of an order (e.g., PENDING, PURCHASED, FAILED, REFUNDED).

Hints

Hint 1

Consider using an asynchronous task queue or an event-driven architecture to decouple the initial request from the long-running process of polling partner APIs.

Hint 2

Use a unique `order_id` generated by the client to achieve idempotency across your internal services and partner bookstores.

Hint 3

Think about the 'Saga pattern' to handle rollbacks if a payment fails after a book has been reserved at a bookstore.

Follow-up questions

  • How would you handle a scenario where the price changes between the initial check and the final purchase confirmation?
  • If a bookstore charges a non-refundable fee for failed transactions, how does that change your retry strategy?
  • How would you implement a circuit breaker to stop hitting a partner bookstore that is consistently returning 500 errors?