Escaping monolithic hell
Why a big single app becomes painful, when a monolith is still the right call, and what microservices give and take.
key idea / coordinatorservice / good pathin progress / watch outproblem / failureneutral
The story: FTGO
FTGO is a food-delivery company. It built everything as one program, a monolith: one codebase, one database, one deployable package. That is a good idea at the start.
Why splitting helps
There are three ways to scale an application. Only the Y axis changes the structure, by cutting the app into services.
The microservice version
Each service has one focused job and talks to others only through its API. The API gateway is the single front door for mobile apps.
Three key ideas
From Building Microservices: three ideas explain what makes microservices work. The one to protect is independent deployability: you can change a service, deploy it and release it without touching any other service, and you do it that way by habit.
To get there, services must be loosely coupled with stable, explicit contracts. That is why they are shaped around a business domain and why each one hides its own data. Sharing a database is one of the worst things you can do to independent deployability. Hiding the data is the same idea as encapsulation in object-oriented code.
Slices, not layers
A classic three-tier system groups code by technology, so even a tiny feature crosses three teams. Microservices group by business function instead. Each service is an end-to-end slice, and the team that owns it is what Team Topologies calls a stream-aligned team.
A microservice in practice
Bootstrapping Microservices defines a microservice as a small, independent process that runs on its own deployment schedule and can be updated alone. One owner (a person or team) is responsible for building, testing, deploying and running it. Alone it does little. A microservices application is many of them, usually in a cluster, working together over the network.
Some services face the outside world, such as the gateway. Others are purely internal. Each usually has its own database or file storage. The same tools appear again and again in that book: Docker to package a service, Docker Compose to try the whole app on a laptop, Kubernetes to host it, and Terraform and GitHub Actions to build the cloud setup.
Three kinds of monolith
Building Microservices calls a system a monolith when everything must be deployed together. That covers three common shapes, and only one of them is bad.
| Kind | Good | Watch out for |
|---|---|---|
| Single-process | Simple to run, test and debug | Everyone shares one codebase |
| Modular | Parallel work, simple deployment | The database is rarely split like the code |
| Distributed | Few: it is a distributed system plus a monolith | Tight coupling and no information hiding |
The modular monolith (Shopify is the book's example) is a real choice, not a failure. Delivery contention, meaning developers and teams getting in each other's way, is the pain that pushes people toward service boundaries.
Monoliths are not all bad
Rocha starts by defending the monolith. A well-structured one is a valid architecture, and a distributed system takes away several things you used to get for free. From Practical Event-Driven Microservices Architecture, ch. 1.
Things a single codebase gives you, and what happens to each when you go event-driven:
| Monolith property | What changes with event-driven microservices |
|---|---|
| Business flow is visible | The flow is spread over events between services. You must follow the events to see the whole process. |
| No network, no versioning | A breaking change needs two event versions side by side and coordination between teams. |
| Run it all locally | The workflow spans many services owned by other teams, each with its own setup. |
| Easy code reuse | Services duplicate code on purpose to avoid coupling. Shared frameworks only for plumbing such as logging. |
| One place to monitor | Dozens of services need central logs, metrics and tracing from day one. |
| End-to-end tests are possible | Mostly not practical any more. Quality comes from other practices (lesson 15). |
| ACID and in-memory locks | Eventual consistency, and locks that must work across instances (lesson 06). |
When the monolith becomes a constrictor knot
The more the business pulls (more users, more data, more developers), the tighter a patchwork monolith pulls back. The book names five pains and says to pick one clear reason before migrating, then measure progress against it. From Practical Event-Driven Microservices Architecture, ch. 1.
| Pain | Why a monolith struggles | What event-driven microservices offer |
|---|---|---|
| Coupling | Boundaries fade. A change to subscriptions can break login. | Services are decoupled by design through events. |
| Team autonomy | Merge conflicts, coordinated releases, hard to scale the team. | Teams own sets of services and agree only on contracts. |
| Release cycle | Every release validates and deploys everything. | Small independent deployments. |
| Scaling | Scale the whole app. The database scales vertically. | Scale one service; each owns its data. |
| Old stack | Unsupported technology, hard to replace as a whole. | Replace one service at a time; mixed stacks allowed. |
Moving is a decision, not a default. A startup still learning its domain should keep a monolith, because redrawing service boundaries later is costly. If the monolith is a patchwork, refactoring it into a modular monolith is the best first step. It may remove the original problem, and it reveals the boundaries.
Gains and costs
Microservices are not a silver bullet. They buy speed and independence and charge you in distributed-system complexity.
The benefits, one by one
Each benefit in Building Microservices follows from small, separate, independently deployable parts.
- Technology choice: pick a graph database for a social graph and a document store for posts, and try a new language on one small service at low risk.
- Robustness: a failure stays behind a service boundary, but only if you design for network and machine failures.
- Scaling: give a busy service more hardware and leave the rest small.
- Ease of deployment: a one-line fix ships alone, so releases stay small and rollback is quick.
- Composability: capabilities become addressable seams that web, mobile and other channels can combine in new ways.
The promise: seven benefits
Each benefit comes from the same mechanism: small services decoupled by a durable broker. From Practical Event-Driven Microservices Architecture, ch. 1.
| Benefit | How it works |
|---|---|
| Evolving architecture | Add a consumer without touching the producer; retire services without breaking dependents; replace a messy service with a new one. |
| Independent deployment | Change the tax calculation in the pricing service and deploy only it. Ownership of the full life cycle moves to teams. |
| Team autonomy | Teams agree on the event contract, then build in parallel. |
| Flexible stack | A geo-distributed store for one service, another database elsewhere; mixed languages. |
| Resilience | Faults stay local; brokers absorb the load; instances can fail over. |
| Tunable scaling | Add consumer instances where lag grows; databases are distributed per service. |
| The past on demand | New consumers replay history instead of running a special migration. |
More pain points
The earlier cost list is just the start. Building Microservices names these problems you should plan for. Most have a fix later in the course, such as sagas for data consistency, tracing for monitoring and contract tests for testing.
Bootstrapping Microservices adds a mindset: microservices bring the pain forward to a point where it is cheaper to handle. They need higher technical skills, and distributed applications are hard, but they give hard boundaries that stop spaghetti code.
When to use them
Building Microservices says the biggest reason to adopt them is letting more developers work on one system without getting in each other's way. A five-person startup will find them a drag. A rapidly growing hundred-person company may find its growth easier.
A new product is still changing its domain model, so service boundaries move and every move is expensive. Uber started with limos and Flickr grew out of a game. Newman treats the monolith as the sensible default. Bootstrapping Microservices argues the opposite: because complexity always arrives, start with microservices and avoid a risky conversion later. Judge by your team size, how stable the domain is and how much operations skill you have.
Not the same as SOA
Older service-oriented architecture used heavy shared infrastructure. Microservices prefer simple connections and private data.
SOA, microservices and event-driven
Event-driven is not "SOA again". SOA with an enterprise service bus organizes around reusable services and lets the bus orchestrate. Microservices and event-driven organize around domains and avoid sharing. In SOA the bus tends to collect business logic and becomes a monolith of its own. From Practical Event-Driven Microservices Architecture, ch. 1.
Most real systems mix both styles. Pure event-driven systems are mostly found in books and proofs of concept. Event streams also change how data is shared: instead of one service pulling a large data set through an API, consumers read the stream and build their own view.
It is not only architecture
Fast delivery needs three things at once: the architecture, a DevOps process, and small teams that own their services.
A map for the rest of the course
The book describes its ideas as patterns grouped by the problem they solve.
The challenges, and where this course covers them
What you give up is the other half of the story. Chapter 1 lists the challenges that the rest of the book answers. Each is a different lesson here. From Practical Event-Driven Microservices Architecture, ch. 1.
Recap
- A monolith is simple at first and painful when big.
- Microservices split by function. Each service owns its data and exposes an API.
- You gain speed and independence. You pay with complexity.
- Start small apps as a monolith. Split when complexity is the real problem.
- You need DevOps and small teams too, not only the architecture.
- Protect independent deployability: loose coupling, domain-shaped services, private data.
- A monolith can be single-process, modular or distributed. Only the distributed one is the worst of both.
- Expect pain in testing, monitoring, data consistency and cost. Turn the dial up slowly.
- A modular monolith is a valid choice. Move only for a clear, measured reason and start with the least risky, most valuable domain.
- Event-driven microservices give evolution, independent deployment, autonomy, resilience, scaling and replay of history, at the price of consistency, concurrency, testing and operations.
Quick check
Show answer
Early on you do not have the problems microservices solve. A distributed system slows down fast iteration, and the best way to find the right service boundaries is to learn the domain first.
Show answer
What specific problem are we solving, and could a modular monolith solve it? Choose a measurable reason such as team size, database scaling or release cycle, and track it during the move.