The Three Neighbours
A backend book can be about the service you write, the components that sit between services, or the composition of many services under requirements. A book that tries to be all three is a survey pretending to be a deep dive. This one is the first, and this topic draws the line precisely: what lives on the other side of it, which course owns each piece, and why Kafka gets one paragraph in this book while sharding gets none.
The line is not a gap in coverage. It is the design. Every chapter ends by naming what it hands off, and the pull to include "just one section" on the thing across the line is resisted on purpose, because the alternative is a book that says a little about everything and lets the reader predict nothing.
The Service You Write
The boundary where bytes become typed values. Identity and authorization. Data access, the pool and the transaction. Failure handling on every arrow. Background work. Caching, as a client of a cache. One outbound integration and the webhook that comes back. Configuration, testing, instrumentation, and what breaks first under load. That is this book, chapter by chapter, and every one of those subjects is treated at the depth of a single service with a single database — which is the depth at which most of them are hard enough.
Between Services: Middleware
Message brokers and their delivery guarantees. API gateways. Service meshes. The choice between a queue, a log and a stream, and what each one promises about ordering and replay. Stagedoor uses one Redis stream as a job queue, and Chapter 8 teaches the stream from the client's side: how to add a job, how to claim one, what "at least once" demands of the handler. It says nothing about choosing Kafka over RabbitMQ, because that is a decision about the thing between services, and the book that owns it is Middleware Deep Dive.
Many Services: System Design
Sharding, consistent hashing, the CAP theorem as a vocabulary for what a split gives up, multi-region deployment, and the decomposition of one service into several with boundaries that survive. Stagedoor stays one service with one database for all fourteen chapters. The last topic in the book is the honest moment where that stops being enough — and it hands the reader to System Design with the vocabulary to ask the right questions rather than a chapter that answers them badly.
Underneath: the Engine, the Container, the Stack
PostgreSQL Deep Dive owns MVCC, the planner, and replication inside the engine; this book owns the pool, the transaction and the migration from the application's side, and Chapter 6 says at every step where the engine's side of the story is told. Docker and Kubernetes own the image and the orchestrator; this book owns what the process must do to be a good citizen inside them: config from the environment, two health endpoints, a clean response to SIGTERM. Chapter 11 stops at the line where the container begins. Observability Deep Dive owns the collector, the storage and the dashboards; this book owns the instrument in the code, and Chapter 13 ends at the /metrics endpoint.
The Two Beginner Books Beneath
APIs for Beginners teaches using an API: what a status code is, what JSON looks like, how to read the docs, how to send a request with curl. Databases for Beginners teaches reading SQL: tables, joins, what a primary key is for. This book assumes both and does not repeat them. When a term from either appears here, it is used as known vocabulary and the page goes one layer down — not "404 means not found" but "404 versus 403 is a decision about what you reveal, and the wrong one enumerates your users."
How the Book Uses the Line
Every chapter names its handoffs. When the reader wants Kafka semantics, sharding or pod scheduling, the page says which course, and moves on. The line is what lets this book spend a whole chapter on the seat that was sold twice and another on the buyer who was charged twice, at a depth that would be impossible if it also had to explain what a broker is. Read the handoff notes as a map of the catalogue, not as apologies.
- Reading this book for a broker comparison — it uses one stream as a client and explains the guarantees the client must live with; the brokers themselves are Middleware's subject, and a reader who expects Chapter 8 to rank them will be disappointed on purpose.
- Expecting a microservices chapter — Stagedoor is one service, the moment it should stop being one is the last topic, and the design of the pieces is System Design's subject.
- Skipping the beginner books because this is "the real one" — the vocabulary of status codes, JSON and SQL is assumed on every page, and a reader without it will be looking things up mid-sentence.
- Treating the handoff lines as gaps — they are what makes the depth possible; a book that covers the broker, the shard and the pod as well covers each of them in a paragraph.
- Reading Chapter 6 without PostgreSQL Deep Dive open beside it — the application side of a row lock is only half the story, and the chapter says so at every step.
- Read APIs for Beginners and Databases for Beginners first if "cursor pagination" and "transaction isolation" are new phrases.
- Read PostgreSQL Deep Dive alongside Chapter 6 for the engine's side of the pool, the lock and the isolation level.
- Keep a list of the Middleware and System Design questions that come up while reading — the courses that answer them are the next rungs, and the list is the reading plan.
- Use the handoff note at the end of each chapter as the map of the catalogue, and follow it when the question in your head is on the other side of the line.
Knowledge Check
Stagedoor's worker consumes jobs from a Redis stream. Which question about that stream does this book answer, and which does it hand off?
- It answers how to claim, acknowledge and tolerate duplicates; it hands off whether Kafka would have been the better choice
- It answers why Redis Streams beats Kafka for this workload; it hands off the handler's duplicate tolerance
- It hands off everything about the stream, because queues of any kind are between services and therefore out of scope
- It answers how the stream stores entries internally and replicates them across nodes; it hands off how the worker claims a job
Why does Stagedoor stay one service with one database for the whole book?
- Because a single service is the simple case and the hard problems only appear once it is split
- Because the ticketing workload is too small to justify more than one service in practice
- Because the mechanisms are hard enough at that depth, and composing many services is System Design's subject
- Because splitting a service is always a mistake and the book is written to prevent it
A reader hits Chapter 11 and wants to know how the orchestrator schedules pods and sets memory limits on the node. What does the book do?
- It covers scheduling in one section, because a service author cannot reason about limits without it
- It teaches what the process must do to be a good citizen and names Kubernetes Deep Dive for the rest
- It skips resource limits entirely, because anything involving a container is out of scope
- It assumes the reader has already read Kubernetes Deep Dive and refers back to it without explanation
You got correct