Explain the Design, Then Defend the Decisions

"Design a library reservation system"

Arjun has spent a year building Meera's library app, through every guide in this series: foundations, networking, messaging and a very bad term. Now he's interviewing for an architect role at a large company. The interviewer smiles and says: "Design a library reservation system." (Arjun, the interviewer and every number here are made up for teaching.)

He knows this system better than anyone, and that is exactly the danger. His instinct is to draw the final architecture from memory, with every box he ever added. That would be a bad answer. Interviewers don't want the finished picture. They want to watch you reason your way to it, and to hear you defend each decision.

A good answer connects decisions to evidence. "Reservations need a transaction because two students may request the same physical copy" is stronger than naming a database without explaining its job. There can be several good designs, but not every design is valid. A design that allows two confirmed reservations for one copy breaks the requirement, however impressive its diagram looks.

This guide follows Arjun's 45 minutes, then the two follow-up questions he gets, then how he prepared:

1. Arjun plans his 45 minutes

Before speaking, Arjun sketches this plan on the corner of the whiteboard:

flowchart TD
    A@{ icon: "algomi:svc-cube", label: "0-5 min: agree on scope and invariants", pos: "b", h: 52 }
    B@{ icon: "algomi:svc-cube", label: "5-9 min: scale, latency, availability, consistency", pos: "b", h: 52 }
    A --> B
    C@{ icon: "algomi:svc-cube", label: "9-15 min: entities and APIs", pos: "b", h: 52 }
    B --> C
    D@{ icon: "algomi:svc-cube", label: "15-25 min: working design and read and write paths", pos: "b", h: 52 }
    C --> D
    E@{ icon: "algomi:svc-cube", label: "25-38 min: two or three important risks", pos: "b", h: 52 }
    D --> E
    F@{ icon: "algomi:svc-cube", label: "38-45 min: operations, limits, summary", pos: "b", h: 52 }
    E --> F

Reading the diagram. It's a top-to-bottom budget of time, and the order is the point:

• The first 15 minutes are spent agreeing on what to build: scope, numbers, data and APIs. No architecture yet.
• The architecture comes at minute 15, and only a working version.
• The longest block (13 minutes) is the risks. That's where an interviewer judges depth.

Adapt it to the interviewer: ask which area deserves more depth. A calculation should support a decision, not eat time without changing the design.

A useful way to phrase every decision: "Because we need X, I would choose Y. It gives us Z, but costs W. I would revisit it if V changes."

2. Minutes 0–38: reserving a library copy

This is an original teaching design. All scale and service targets are assumptions, not measurements of a real system.

Step A (minutes 0–9): agree on scope

Arjun asks questions before drawing anything, and they agree on the following.

• In scope: students search the catalogue, reserve an available physical copy, view their reservations, and cancel before collection. Staff mark a reservation ready and collected.
• Out of scope for version one: delivery, recommendation ranking, transfers between schools and complex waiting lists.
• The key invariant: one copy has at most one active reservation. Search availability may be slightly stale, but a confirmation must come from authoritative data.
• The numbers, from guide 1: 100,000 daily active students, about 231 peak searches per second under an assumed 10× peak factor, and 10,000 reservations a day. He proposes p95 search latency under 300 ms and a 99.9% request success SLO, then checks they suit the interviewer.

Step B (minutes 9–12): define the data

The most important distinction is between a title and a physical copy. Five copies of one title can be reserved by five students. The invariant belongs to the physical item.

erDiagram
    BOOK ||--o{ COPY : has
    COPY ||--o{ RESERVATION : has_history
    STUDENT ||--o{ RESERVATION : makes
    RESERVATION ||--o{ OUTBOX_EVENT : produces

Reading the diagram. It's an entity-relationship diagram. The symbols at each end of a line give the count: || means "exactly one" and o{ means "zero or many". So each line reads:

• One BOOK has many COPIES: five physical copies of one title.
• One COPY has many RESERVATIONS over time. That includes the history: past, cancelled and collected reservations.
• One STUDENT makes many RESERVATIONS.
• One RESERVATION produces events, such as "created" and "ready".

What the diagram can't say is "only one active reservation per copy at a time". That rule needs a separate database constraint (step E). Diagrams show shape, and constraints enforce rules.

Step C (minutes 12–15): define the API