Design a Library Management System

Beginner · 22 min read · Low-Level Design, Case Studies: Core

Catalog, members, loans, reservations and fines.

The library system is a classic domain-modelling problem. There's little algorithmic difficulty; the grading is about getting the entities and relationships right — especially the difference between a book (a title) and a book copy (a physical item) — and handling business rules like borrowing limits, reservations and…

What the interviewer expects

The full design in this lesson is longer than anything you'd write in one round. It's there so you understand the edge cases and can answer follow-up questions. In the round itself, aim for this:

1. Requirements

2. Domain model

The most important modelling decision:

3. Implementation

The copy guards its own state transitions — business rules live with the data (tell, don't ask).

4. Concurrency

Two members could try to check out the same copy simultaneously (self-checkout kiosks), or a return and a reservation could interleave. For an interview, synchronising the service's mutating operations (as above) is a correct baseline; finer-grained options are a lock per copy/ISBN or optimistic versioning in the…

5. Patterns used

Interview questions

• Why separate Book from BookCopy?
• How do reservations interact with returns?

Further reading

Key takeaways

• Model titles (Book) and physical items (BookCopy) separately — the key domain decision.
• Guard state transitions inside entities; keep rules like fines and loan limits as strategies.
• Reservations are a FIFO queue per title that converts returns into holds.
• Inject Clock for due dates, fines and hold expiry.

Previous: Design a Logging Framework · Next: Design an In-Memory File System