Description
You split the monolith so teams would stop stepping on each other, and six months later one feature touches five services, a single deploy takes down three more, and a call that used to be one line now fails halfway and leaves a paying customer with nothing to hand back. Microservices are sold as the cure for a tangled monolith and are usually a way to turn one hard problem into a dozen harder ones. The moment you split a system across the network, a function call becomes a request that can be slow, fail, or arrive twice, a transaction that used to be one commit now spans services that can each fail halfway, and a schema change becomes a coordination problem across teams. Most microservice pain is self-inflicted: boundaries drawn around nouns instead of around change, services so chatty they are a distributed monolith with worse latency, shared databases that couple everything they were meant to separate, and no plan for the failure that is now constant. The skill is not running containers, it is knowing where to cut, how services should talk, and how to operate a system where the network is always partly broken.
This book teaches you to design and operate microservices that actually buy you the independence they promise, instead of a distributed monolith that has every cost of services and none of the benefits. It starts from the only honest question (do you even need them, and what a monolith does better) and the one that decides everything else: where to draw service boundaries, around business capabilities and the axes of change rather than around database tables, so a typical change touches one service and not seven. It builds the communication layer carefully: synchronous calls and their failure modes, asynchronous and event-driven messaging and why it decouples services, and the patterns that keep them honest (timeouts, retries with backoff, idempotency, circuit breakers, and the dead end of distributed transactions versus the saga pattern). It confronts data head-on: a database per service, why a shared database recouples everything, and how to keep data consistent across services without a global transaction. Then it gets operational, because that is where microservices are won or lost: how a request finds a service, the API gateway, observability across a call that spans ten services (tracing, correlation ids, and the logs you will live in), versioning a contract without breaking consumers, and testing a system you cannot run whole on your laptop. It closes on the migration: strangling a monolith one capability at a time instead of a rewrite. The examples are a real system, shown split badly and then well. For engineers who want services that can change independently, not a monolith scattered across the network.
Who this was written for
This book is for: engineers and leads who are about to split a monolith, or already run a fleet of services, and want the boundaries, the communication, and the operational reality of microservices to work for them instead of becoming a distributed monolith nobody can change.
The shortcut nobody hands you
The 6 Steps to Becoming the Architect Trusted to Decide Where the System Splits. The method for cutting a system into services that actually change independently, instead of a distributed monolith with every cost of microservices and none of the freedom. One test decides every move, from where you draw the boundary to how services talk, own their data, and get operated, so a typical change touches one service and not seven. Go from a monolith you’re afraid to touch to services that move on their own.
- Decide if you even need them
- Cut boundaries around change, not tables
- Connect services without recoupling them
- Isolate data with one database per service
- Operate a system you can’t hold in your head
- Migrate the monolith one capability at a time
Every chapter, laid out
- Chapter 1: The day one line of code stopped being safe
- Chapter 2: Do you actually need microservices?
- Chapter 3: Cut in the wrong place and one feature touches five services
- Chapter 4: How a chain of service calls multiplies your downtime
- Chapter 5: What if your services never had to wait for each other?
- Chapter 6: The network is always partly broken
- Chapter 7: The one SELECT that turns your services back into a monolith
- Chapter 8: The customer paid and there’s nothing to roll back
- Chapter 9: When painting one screen means four network calls
- Chapter 10: The request looked fine in every log and still failed
- Chapter 11: You changed one field and broke a service you’ve never opened
- Chapter 12: Why the big rewrite almost never ships
- Chapter 13: Did you build microservices, or a monolith on the network?
