Design a Library System
A university library lets members search the catalogue, check books out and return them, and get reminders about due dates. Searching dominates, but a checkout must never hand the same copy to two people. At the start of each semester traffic multiplies, and a reminder job emails members through an outside provider.
Constraints
- Search and checkout must respond within 200 ms
- About 3,000 requests per second at peak, and about 1 in 8 is a checkout or return
- The same copy of a book must never be checked out to two people
- The semester rush is about three times the normal load
- Overdue reminders go out through an external email provider
- Keep infrastructure under $4,000 a month
- The catalogue holds about 2 million books and 8 million loan records, for about 60,000 members
Scenarios to survive
Regular term
Normal term-time traffic.
Interviewer asks: Searching and checking out have very different needs. How does that change where each one runs and what it talks to?
Semester rush (3x)
The first week of term triples traffic.
Interviewer asks: Locks protect checkouts but slow writes. How do you keep searching fast while checkouts queue behind locks?
Primary database fails
The main catalogue database loses a node.
Interviewer asks: Which requests can still be served from a replica or a search index, and which must stop to stay correct?
What a good design must do
- Requests meet the latency target at peak
- At least 98% of requests are served during the semester rush
- Total monthly cost stays within $4,000
- Searching uses a search index, not the main database
- Something handles checkouts, and never lends one copy twice
- Something sends overdue reminders
- The design explains how the search index stays in step with checkouts
- Every query is answered through a key or an index, never by reading a whole table