System Design Interview
Library management system: circulation with row-locked transactions, a catalog search index, read scaling for the semester rush, first-come hold lines with email notifications, and fines recorded on return. A teaching design.
See the race in lending and why SQL text search doesn't scale.
What was missing: Nothing yet.
Why that's risky: Two desks can lend the same copy at the same moment, LIKE queries scan the whole catalog, and the semester rush overloads one server.
What gets added: One server that searches with SQL LIKE queries and lends a book by checking a copy is available and then recording the loan.
Trade-offs: Simple, but correctness depends on timing.
Make lending correct under concurrency and make search fast.
What was missing: Lending was check-then-insert, and search scanned the catalog.
Why that's risky: At semester start every record page and availability check still reads the primary database.
What gets added: App servers behind a load balancer where borrow and return lock the copy's row inside a transaction (and a late return records its fine in the same transaction), plus a catalog search index kept up to date by an indexer.
Trade-offs: Search results can lag a new catalog record by a few seconds.
Handle ten times the usual traffic without loading the primary.
What was missing: Every read went to the primary.
Why that's risky: Patrons can't line up for a book that's out, so popular titles go to whoever checks the shelf first.
What gets added: An availability cache updated on every borrow and return, and a read replica for record pages and patron history.
Trade-offs: Availability shown in search can be a moment stale; the transaction at the desk is always authoritative.
Let patrons join a line for a book and tell them when it's their turn.
What was missing: No holds: popular books went to whoever happened to check.
Why that's risky: Nothing limits scrapers, and nobody sees failed emails or slow desk transactions.
What gets added: Holds stored as a first-come line per title; when a copy is returned with a line waiting, a notifier sets it aside for the first patron and emails them, passing it on after three days.
Trade-offs: A set-aside copy is unavailable to others for up to three days.
Protect the catalog from scrapers and watch the system.
What was missing: No limits and no visibility.
Why that's risky: Remaining risk is small: a library this size runs fine in one region with backups.
What gets added: A rate limiter per patron and IP, and monitoring of search latency, desk transaction errors and notification delivery.
Trade-offs: Strict limits could slow a librarian doing bulk work; staff accounts get higher limits.
Use a dedicated search index with inverted indexes and async sync from the primary database.
Invalidate cache on checkout and return events and use short TTLs for availability data.
Use async queues, worker pools, and idempotency to guarantee delivery and avoid duplicates.
Apply rate limiting at the edge and API gateway to throttle abusive clients and protect backend resources.
Integrate monitoring and logging services at every tier, with alerting on latency, error rates, and business KPIs.
A circuit breaker prevents cascading failures and protects the notification flow if the notification service is slow or down.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
