Katkat
Back

Design a Multi-Branch Library Lending System

AmazonSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests the ability to design a distributed inventory and reservation system, focusing on concurrency control, transaction integrity across branches, and fault-tolerant service communication.

Problem: Multi-Branch Library Lending System

Design a backend system for a library chain with multiple physical branches. Each branch has its own collection of books, but users can search across the entire network and reserve items from any branch.

Requirements

Functional Requirements:

  1. Catalog Search: Users search for a book title and view real-time availability across all branches.
  2. Reservations: Users can place a reservation on a book copy. A copy must be marked as 'reserved' so no one else can check it out.
  3. Checkout/Return: A workflow to transition a book from 'Available' to 'Checked Out' and back to 'Available' upon return.
  4. Branch Awareness: The system must track which branch holds which physical copy.

Non-Functional Requirements:

  1. Concurrency: Prevent double-booking. If two users request the last available copy at the same time, only one should succeed.
  2. Availability vs. Consistency: How do you handle search results when a branch's local system is temporarily unreachable?
  3. Idempotency: Ensure that network retries during the checkout or return process do not result in duplicate state changes.

Deliverables

  1. API Design: Define the primary endpoints for searching, reserving, and checking out.
  2. Data Model: Propose a database schema (relational vs. NoSQL) to store book metadata, branch inventory, and loan states.
  3. System Architecture: Sketch the services (e.g., Search Service, Inventory Service, Lending Service) and explain how they communicate.
  4. Handling Failure: Describe how to handle a failure occurring mid-transaction (e.g., the system updates the local branch inventory but fails to notify the user/update the global loan history).

Hints

Hint 1

Consider using a distributed locking mechanism or a database transaction with 'select for update' logic to manage the inventory state for specific book copies.

Hint 2

Decide whether to use a synchronous two-phase commit or an asynchronous event-driven approach with a message queue (e.g., Kafka) to handle state transitions between services.

Hint 3

Address the 'Read-Your-Writes' consistency problem by using versioning or timestamps on book availability status to filter out stale data during search.

Follow-up questions

  • How would you handle a scenario where a user reserves a book, but the physical copy is damaged or lost before they arrive to pick it up?
  • If the library wants to support a 'waitlist' feature, how would you modify the reservation system to handle queues per book?
  • How would you implement a background job to handle overdue book notifications without putting heavy load on the primary transaction database?