Design a Library Management System

A library management system works by separating the abstract thing a reader searches for (a Book — one ISBN, one title) from the physical thing they carry home (a BookItem — one barcode, one copy on one rack), so that loans, reservations, fines, and availability are all tracked per copy while search and catalog stay per title. Almost every requirement in this problem — "check out any copy", "reserve when none available", "who has this exact book" — falls out cleanly once you make that one split. Get the split wrong and the whole model fights you.

The core decomposition (and why)

The single most important modeling decision is the Book vs BookItem distinction. A reader searches the catalog for "Designing Data-Intensive Applications" — that is one Book (ISBN 978-1449373320). But the library owns three physical copies, each with its own barcode, rack, and loan state. Those are three BookItems. This is why each layer holds different responsibilities:

An alternative some candidates reach for is folding lending and reservation state into boolean flags on BookItem (isLoaned, reservedBy). It compiles and demos fine — but it loses history (you can't answer "who borrowed this last March"), it can't model a reservation queue, and it can't represent "returned late, fine pending" without a third flag. Modeling lending and reservation as their own records keeps BookItem a thin state holder and pushes the workflow into objects you can query and audit.

Worked example: returning a book 3 days late

The fine path is where the original code was broken, so trace it with real values. Member M-42 borrowed copy LIB-0002; the library allows MAX_LENDING_DAYS = 10. Assume a flat fine of $0.50 per day late. The dates:

That arithmetic only runs if the code names the right variable. The original wrote today.compareTo(...) on one line and then todayDate.getTime() on the next — two different names for the same instant. It does not compile, so the fine is never computed.

Why the naive version is wrong

The shipped code had three defects that all prevent compilation, plus a behavioral bug. Each is small, and each is the kind of thing an interviewer will catch:

1. Undeclared variable. checkForFine declares Date today = new Date(); then uses todayDate.getTime(). todayDate was never declared — compile error. (It also reads memberId, which isn't in scope; the fix threads it through from the lending record.)
2. Phantom enum constant. Both checkoutBookItem and renewBookItem call bookReservation.updateStatus(ReservationStatus.COMPLETED), but ReservationStatus only defines WAITING, PENDING, CANCELED, NONE. COMPLETED doesn't exist — compile error, and a real modeling gap: there was no way to mark a reservation fulfilled. The fix adds COMPLETED.
3. Non-existent type. public bool renewBookItem(...) — Java has no bool type; the keyword is boolean. Compile error.

Here is the corrected Member class. The enum gains COMPLETED, today is used consistently, memberId is read from the lending record, and renewBookItem returns boolean:

public enum ReservationStatus {
    WAITING, PENDING, CANCELED, COMPLETED, NONE   // added COMPLETED
}

public class Member extends Account {
    private Date dateOfMembership;
    private int totalBooksCheckedout;

    public int getTotalBooksCheckedout() { return totalBooksCheckedout; }
    private void incrementTotalBooksCheckedout() { totalBooksCheckedout++; }
    private void decrementTotalBooksCheckedout() { totalBooksCheckedout--; }

    public boolean checkoutBookItem(BookItem bookItem) {
        if (getTotalBooksCheckedout() >= Constants.MAX_BOOKS_ISSUED_TO_A_USER) {
            ShowError("User already has the maximum number of books checked out");
            return false;
        }
        BookReservation reservation =
            BookReservation.fetchReservationDetails(bookItem.getBarcode());
        // reserved by someone else -> refuse
        if (reservation != null && !reservation.getMemberId().equals(getId())) {
            ShowError("This book is reserved by another member");
            return false;
        } else if (reservation != null) {
            // this member's own reservation is now fulfilled
            reservation.updateStatus(ReservationStatus.COMPLETED);
        }
        if (!bookItem.checkout(getId())) return false;
        incrementTotalBooksCheckedout();
        return true;
    }

    private void checkForFine(String bookItemBarcode) {
        BookLending lending = BookLending.fetchLendingDetails(bookItemBarcode);
        Date dueDate = lending.getDueDate();
        Date today   = new Date();
        if (today.compareTo(dueDate) > 0) {                 // overdue
            long diff     = today.getTime() - dueDate.getTime();  // was todayDate
            long diffDays = diff / (24L * 60 * 60 * 1000);
            Fine.collectFine(lending.getMemberId(), diffDays);    // memberId from record
        }
    }

    public void returnBookItem(BookItem bookItem) {
        checkForFine(bookItem.getBarcode());
        BookReservation reservation =
            BookReservation.fetchReservationDetails(bookItem.getBarcode());
        if (reservation != null) {
            // someone is waiting -> hold it for them, notify
            bookItem.updateBookItemStatus(BookStatus.RESERVED);
            reservation.sendBookAvailableNotification();
        } else {
            bookItem.updateBookItemStatus(BookStatus.AVAILABLE);
        }
        decrementTotalBooksCheckedout();
    }

    public boolean renewBookItem(BookItem bookItem) {          // was 'bool'
        checkForFine(bookItem.getBarcode());
        BookReservation reservation =
            BookReservation.fetchReservationDetails(bookItem.getBarcode());
        // reserved by someone else -> cannot renew, hand it over
        if (reservation != null && !reservation.getMemberId().equals(getId())) {
            ShowError("This book is reserved by another member");
            bookItem.updateBookItemStatus(BookStatus.RESERVED);
            reservation.sendBookAvailableNotification();
            return false;
        } else if (reservation != null) {
            reservation.updateStatus(ReservationStatus.COMPLETED);
        }
        BookLending.lendBook(bookItem.getBarcode(), getId());
        bookItem.updateDueDate(LocalDate.now().plusDays(Constants.MAX_LENDING_DAYS));
        return true;
    }
}

Note one behavioral fix beyond the compile errors: the original returnBookItem always ended by setting the item to AVAILABLE even after setting it to RESERVED for the next member, silently dropping the hold. The corrected version uses an else so a reserved copy stays reserved. It also decrements the member's count on return, which the original omitted — without it, a member who returns five books still shows five checked out and can never borrow again.

Pitfalls

• Comparing IDs with ==. The original wrote bookReservation.getMemberId() != this.getId(). If memberId is a String, == compares object references, not values, so a member can be wrongly told their own reserved book belongs to someone else. Use .equals() (or make IDs a value type).
• The set-then-overwrite status bug. Setting an item to RESERVED and then unconditionally to AVAILABLE in the same method makes the reservation queue silently leak — the next member is notified the book is ready, but the catalog shows it as free for anyone to grab. Guard mutually exclusive state transitions with else.
• Day count off-by-one and rounding. Integer division diff / 86_400_000 truncates: a book 47 hours late counts as 1 day, not 2. Decide deliberately whether you charge per started day (Math.ceil) or per completed day, and beware daylight-saving shifts — prefer LocalDate.until(...) over millisecond subtraction for calendar-day math.
• Forgetting to decrement on return/renew. The MAX_BOOKS_ISSUED limit is enforced on checkout but only correct if returns decrement the counter. Miss it and active members lock themselves out.
• Reservation has no queue. A single reservedBy field can't model two members waiting on the last copy. Real systems keep an ordered BookReservation list per book and notify the head of the queue on return.

Takeaways

• Split the abstract Book (ISBN, searchable) from the physical BookItem (barcode, loanable). Almost every requirement resolves once this split is right.
• Model lending, reservation, and fine as their own records, not booleans on the item — you gain history, an auditable money trail, and a real reservation queue.
• State transitions that are mutually exclusive (RESERVED vs AVAILABLE) must be guarded with else; counters touched on checkout must be undone on return.
• In an interview, compiling Java still matters: boolean not bool, declare what you use, and only reference enum constants that exist.

Re-authored and deepened for this guide. The Book/BookItem decomposition, use cases, and class roles follow the classic treatment in Grokking the Object Oriented Design Interview (Design Gurus / educative.io). The three compile defects (todayDate vs today, the missing ReservationStatus.COMPLETED, and bool vs boolean), the set-then-overwrite status bug, and the missing decrement-on-return were identified and fixed here; the fine worked example uses concrete dates. Java type and date-handling guidance per the Java Language Specification and java.time (JSR-310) documentation.