Let Each Part Do Its Job: How One School Library App Grew Up
Algomi Research · Created 2026-09-15 · Updated 2026-10-15 · System Design
The one problem this whole guide solves
Meera is the librarian at a school with 1,200 students. Every morning the same thing happens. A student runs to the desk asking for a book, and it has already gone to someone else. Meera wants one simple thing:
A student reserves a book on their phone, and the book is waiting at the desk when they arrive.
Arjun, the computer-science teacher, offers to build it. We will follow that one feature, a reservation, from a small program to a system that serves forty schools. (Meera, Arjun, the school and every number here are made up for teaching.)
The rule for this guide is the same rule you should follow in an interview: nothing gets added until a real complaint forces it. Each section below starts with a complaint, then shows the idea that fixes it and what that fix costs.
| Chapter | The complaint | The idea it forces |
|---|---|---|
| 1 | "Where do I even put the code?" | Layers and tiers |
| 2 | "Forty schools, two teams, one codebase" | Modular monolith vs microservices |
| 3 | "The report froze the reservation desk" | Synchronous vs asynchronous work |
| 4 | "Search, SMS and analytics all need to know" | Commands, events, queues, pub/sub, streams |
| 5 | "A student got the SMS twice" | Delivery guarantees and idempotent consumers |
| 6 | "We chose Kafka. Now what?" | Partitions, keys, consumer groups |
| 7 | "The SMS gateway went down for an hour" | Retries, backoff, dead-letter queues |
| 8 | "The book was reserved, but search never heard" | Transactional outbox |
| 9 | "Book the science-fair hall, projector and a helper" | Sagas |
| 10 | "Who held this book last March?" | Event sourcing and CQRS |
| 11 | "The reservation code is turning into spaghetti" | Object design patterns and SOLID |
1. Day one: "Where do I even put the code?"
Arjun's first version is one program and one database. A student taps Reserve, and the program checks the book is on the shelf and saves the reservation. That is the smallest design that works.
Reading the figure. There are four parts and two arrows.
| Part | What it is | In Meera's library |
|---|---|---|
| Student app (client) | The phone or web screen the student uses. It only asks; it never decides whether a book is free. | The student at the counter |
| Catalog (service) | Answers "which books exist, and where are they?" The browse arrow is the student searching it. | The card catalogue |
| Reservation (service) | Applies the rules: the copy is on the shelf, the student holds fewer than three books. Only this part may create a reservation. | Meera at the desk |
| Domain tables (data store) | The database tables that hold the real state: books, copies, reservations. The commit state arrow means the reservation is saved permanently before the student is told "confirmed." | The reservation ledger |
The shapes follow one legend in every figure: a coloured tile is a service (code that runs), a cylinder is a data store, and a line icon is a person, app or outside system. Solid arrows are direct calls where the caller waits. Catalog and Reservation are separate boxes even though, on day one, they run in one program. They are separate responsibilities (layers and modules), not yet separate machines (tiers).
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
See plansSources
- Kafka design documentation — Apache Kafka
- AWS transactional outbox guidance — AWS
- CQRS pattern — Microsoft