Home/Low-level design/Library Management System

Library Management System

Title identity, copies, and loan ownership

A title identifies a logical work; a copy identifies one lendable physical instance. Multiple copies of the same title may be loaned to different members, but a member's active title constraint spans every copy.

go
type CopyID string
first, second := CopyID("C1"), CopyID("C2")
fmt.Println(first != second) // distinct copies can share a title

Check duplicate member-title ownership before checking availability, so exhaustion does not hide an invalid duplicate request. Return operations need the current loan owner; unknown and already returned copies are harmless misses, while another owner's return is an error. Store immutable inventory separately from mutable loans. Deterministic smallest-copy allocation keeps behavior reproducible.

Go models this service with a struct and pointer-receiver methods. Constructor functions return a pointer; validation failures return errors rather than panicking. Scalars in snapshot structs are copied by value. Maps, slices, and optional pointers still require detached copies when crossing the service boundary. Go maps do not have key iteration order; use ordered slices for ranked results. There are no threads, persistence, wall-clock reads, or external side effects in this exercise.

Put it into practice

Implement the exercise in a full-screen workspace, then run its tests.

Open practice
Next lessonLRU Cache