Library Management System – Low Level Design Interview Practice
Practise the Library Management System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Modelling discipline rather than pattern recall: the book/copy distinction, and keeping lending rules out of the member class.
Requirements to establish first
- Catalogue books, and distinguish a title from the physical copies of it.
- Search by title, author, subject and publication date.
- Issue a copy to a member, with a limit on how many a member may hold.
- Return a copy, calculating a fine when it is late.
- Reserve a title whose copies are all out, and notify the member when one comes back.
Core classes
- Book – The bibliographic record: ISBN, title, author, subject. One per title.
- BookItem – One physical copy, with a barcode, a location and a due date. This separation is most of the question.
- Member – Identity and current loans. Not the rule about how many are allowed.
- Loan – Which copy, which member, issued when, due when, returned when.
- LendingPolicy – Loan limits, loan length and fine rate, which differ by member type.
- Catalogue – The search index over books, keyed per searchable field.
Design patterns that apply
- Strategy – A student, a staff member and a visitor get different limits and fines. One policy interface, three implementations, no conditionals in Member.
- Observer – Reservation notification: a returned copy notifies whoever is waiting, without the return path knowing who that is.
- Factory – Member creation by type, so the right policy is attached once.
Follow-up questions to expect
- Two members reserve the last copy. Who gets it when it returns, and where does that queue live?
- A member's fine is unpaid. Does that block new loans, and is that the policy's decision or the member's?
- Add e-books, which have no physical copy and no due date. Does BookItem survive that?
Where candidates lose marks
- One Book class carrying both the title and a copy count, which cannot express "copy 3 is damaged".
- Fine calculation inside Member or Loan rather than in a policy that can vary.
- Search implemented by scanning the whole catalogue, with no comment on why that is acceptable at this scale.