Microservices Recipes argues that most services should not exist

The argument is against splitting, not for it

The book's own framing is the most useful thing about it. The readme leads with the definition from Sam Newman's Building Microservices, that microservices are small, autonomous services that work together, and points out that this definition carries two requirements at once, independence and interoperability.

From there the book takes a position that is unusual for a title about microservices: stop splitting, start governing. The named contribution is Adaptive Granularity Governance, presented as the Khan Microservice Pattern, and the descriptions in the chapter list are written as arguments rather than as topics. A boundary earns its keep only when all three conditions hold, and the chapter on it, the longest in the book at 70 minutes, defines a fulcrum, an RVx measure, an SCS and a KM3, with honesty tiers. Part IV is dedicated to that single chapter.

The strongest version of the argument arrives in the migration part rather than the theory. The right number of services is often one, and the chapter on the modular monolith covers enforced modules, schema-per-module grants, and extraction on evidence, that is, splitting a service only when you can show it should be split. The preface makes the same point in a line, why a boundary has to earn its keep.

So this is not a book that hands you a service decomposition. It is a book about how to decide, and about what to do when a decomposition has already gone wrong, which is what the Distributed Monolith chapter is for: diagnosing one, with connascence, Conway's Law, contracts and a first resilience gate.

Eight parts, and read times that suggest how to use it

The book is organised as parts with a stated focus, and the table of contents gives a read time for every chapter, from 35 minutes for the introduction to 70 for the Khan pattern chapter. That is a useful signal about what kind of document this is: it is meant to be read in pieces, as a reference you return to rather than a narrative you read once.

Part I is the sociotechnical substrate, about aligning the organisation and the architecture to prevent the distributed monolith. Part II is data architecture, and its chapter titles are the argument in miniature: the end of ACID, the consistency tax of spanning services, close the dual write then survive failure, and every hop is a door, prove who is knocking.

Part III covers inter process communication, with chapters on emitting evidence before you try to debug, testing the agreements rather than the whole system, and publishing what happened rather than waiting.

Part V is resilience engineering and advanced scaling, with shuffle sharding inside cells and chaos engineering, game days and metastable retries. Part VI is the platform engineering shift, about desired state and locked state, golden paths and telemetry economics.

The front matter is unusually thorough for a book that is nominally free, and it is worth reading before the chapters, because it tells you what you are allowed to do with the thing.

- [Preface](PREFACE.md) - why a boundary has to earn its keep
- [About the Author](AUTHOR.md) - Viquar Khan
- [Mentorship](MENTORSHIP.md) - free 1:1 on ADPList
- [Licensing](LICENSING.md) - MIT for code; CC BY-NC-ND 4.0 for prose and figures
- [Naming](NAMING.md) - methodology title and attribution
- [Citations](CITATIONS.md) - how to cite this work
- [Copyright](COPYRIGHT.md) - owner and dual license
- [Disclaimer](DISCLAIMER.md) - legal notice

The data chapters are the ones engineers argue about

Part II is where the book gets specific about distributed data, and the chapter list reads like a set of positions rather than a survey.

The end of ACID covers the consistency dial, CRDTs, cloud internals and data ownership, and The Consistency Tax of Spanning Services covers sagas, compensation, choreography against orchestration, and isolation. The framing of a tax is deliberate: spanning a service boundary to keep data consistent has a cost, and the book asks you to name it rather than accept it silently.

Close the Dual Write, Then Survive Failure is the practical chapter, with outbox, timeouts, breakers, backpressure and error budgets. The dual write is the bug where a service writes to its database and publishes an event, and one of the two succeeds. The prescribed fix is the outbox, and the chapter continues into what happens after the write is made safe, which is surviving failure with backpressure and error budgets rather than pretending the message bus will behave.

The security chapter, Every Hop Is a Door, covers zero trust, tokens, secrets and agent capability limits, and it is the one place in the book where the word agent appears in a security context rather than an AI context.

Together these four chapters form a coherent position. Boundaries are not free, the consistency guarantee you get by spanning them is a choice with a price, the writes that leave your service need a design, and every new hop is a new place to be attacked.

Evidence first: observability, agreements, and messages that do not wait

Part III is the operational half of the argument, and its three chapter titles are instructions.

You cannot attach a debugger, emit the evidence first, and the chapter behind it covers metrics, structured logs, traces, OpenTelemetry and burn-rate alerts. The point is that in a distributed system the debugging experience you had with a single process is gone, and the substitute is instrumentation you decided to put in before you needed it.

There is no whole system to test, test the agreements, with the pyramid, contracts, async tests and testing in production. That is the standard contract-testing argument, phrased as a consequence of the architecture: if the system is only reachable in pieces, then the pieces' contracts are the testable surface.

Publish what happened, do not wait, covers backpressure, poison messages, idempotency and claim check. The distinction that matters is between a request and an event: an event is a statement about something that already happened, so a consumer that is not ready for it must not block the publisher.

Together, these chapters are a coherent stance on how a system behaves when parts of it are slow or missing, and they are the parts of the book most likely to be useful even to a team that rejects the rest of its argument.

Resilience, platform, agents and the migration path

The back half of the book covers the operational machinery and the two hardest topics.

Shuffle sharding is presented as blast radius control, with the claim that a single bad shard should be a footnote, and chaos engineering as breaking it on purpose, watching, and then you know, with game days, FIS abort alarms and metastable retries. The infrastructure chapter has the book's clearest formulation of platform engineering: the definition is the truth and reality is reconciled toward it, with desired state, locked state, three-layer policy and version-pinned golden paths. The observability chapter argues for spending the budget on answers, with wide events, tail sampling, an eBPF cross-check and retention tiers.

Part VII is where the book deals with probabilistic components inside deterministic architectures, and the framing is a separation of concerns. The model proposes and the executor disposes, which is about planner versus executor, a tool gateway and bounded multi-agent design. Retrieval as a data-plane discipline, not a prompt trick, covers ACL prefiltering, hybrid retrieval, pinned embeddings and shadow evaluation. The recurring idea is that a probabilistic component should sit behind a deterministic boundary that decides what it is allowed to do.

Part VIII is the migration discipline, and it is the part to read first if you are about to do any of this. The right number of services is often one, then the modular monolith chapter, then a strangler chapter whose title is cut off in the copy available here, followed by what looks like a further migration chapter. The stated focus is monolith-first discipline and incremental replacement.

The repository backs the prose with directories named reference-impl/, reference/, validation/ and tools/, which is the part to check before treating the advice as settled.

Openly licensed, DOI registered, and versioned

The licensing is split, and the split is documented in the front matter and in a dedicated file.

Code is MIT, and the prose and figures are CC BY-NC-ND 4.0. The readme's badges say the same: MIT for the code, CC BY-NC-ND 4.0 for prose and figures. There are separate files for the licensing detail, the copyright owner and the dual licence, a disclaimer, and a page on academic use that says the full book is public and asks you to cite it.

The non-commercial and no-derivatives clauses on the prose are the part to notice. A reader can share the book and cite it, but the text itself cannot be republished commercially or adapted into a derivative work, which is a stricter grant than most people expect from something described as freely licensed. The code under MIT is the permissive half, and the reference-impl/ and tools/ directories are the practical part of what you can reuse.

For citation there is more than a wish to be mentioned. The book carries a Zenodo DOI badge and a .zenodo.json file, a CITATION.cff with machine-readable citation metadata, a CITATIONS.md page, a VERSION-HISTORY.md and a CHANGELOG.md. That is the shape of a work intended to be cited in academic writing rather than merely read.

On maintenance, the repository is not archived and the last push was on 2026-09-08, the same day as the only tagged release, v2.1.0, described as the 23-chapter science edition. The content is published on GitHub Pages and the book is a GitBook layout, with a .gitbook.yaml, a SUMMARY.md that holds the table of contents, a Gemfile, a Jekyll config and a layouts directory for the pages site. The .github directory, CONTRIBUTING.md and the validation directory suggest the writing is checked by something in the repository rather than left to review by eye.

Editorial conclusion

Microservices Recipes fits an architect or senior engineer who already knows the vocabulary of distributed systems and wants a structured argument for when boundaries are justified, along with the vocabulary to defend one. It is a poor fit if you want copy-paste service templates, and the repository's own reference implementation is the part to look at before adopting its advice wholesale. Check first which of its patterns your organisation already uses, whether the reference implementation matches the language and framework you deploy in, and that the dual licence of MIT code and CC BY-NC-ND prose fits how you intend to reuse it, since the non-commercial clause on the text is stricter than most readers expect.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vaquarkhan/microservices-recipes-a-free-gitbook on GitHub