Module Introduction

1. What This Module Covers

Most engineers learn microservices in the wrong order. They start with the patterns, the tooling, and the vocabulary, and only much later ask whether the system needed to be split at all. That last question is the one that decides whether the design works, and this module answers it.

There are two ways to build a large application. A monolith is one program that holds every feature and is released as a single unit. Microservices are many small programs that each own one part of the job, run on their own, and talk to each other over a network.

Choosing between them is the first real decision in any service based design, and almost everything later in this course depends on getting it right. Microservices are not a performance upgrade. They solve an organizational problem. They exist so that many teams can build and release their own work without waiting for each other. A single team gets almost none of that benefit and still has the full cost.

That cost has three parts, and you will see all three again in later modules. Every call between services becomes a network call, which means it can be slow, fail, or arrive twice. Data spreads across separate databases, so keeping it correct becomes your job and not the database's job. And one thing to run becomes many things to deploy, monitor, and repair.

This is not just a theory. Several well known engineering teams have merged services back into larger ones after paying that cost, and have written publicly about how much simpler and cheaper the result was. Splitting a system can be undone later, but it always costs something.

By the end of this module you will be able to look at a real system, say whether it should be split into services, and defend that answer with evidence rather than with what is popular.

💡 The most valuable skill in this module is not naming patterns. It is knowing when a pattern is the wrong tool, and being able to say why.

2. The Lessons

3. Two Terms Used Throughout

1. Deployment unit. A deployment unit is the thing you build, test, and release as one piece. A monolith is a single deployment unit, while a microservices system has many, and each one is released on its own schedule. Most of the trade-offs in this course come back to that one number.
2. Independently deployable. A service is independently deployable when one team can release a change to it without waiting for another team. This is the property that makes microservices worth their cost, and it is also the one most teams fail to achieve. Here is the test. If every release still needs three teams to deploy together, you are not getting the benefit, no matter how many services you have.

4. Before You Start

Pick a system you know well, at work or from a side project, and answer three questions about it. Simple answers are fine, because the module will improve them.

1. How many engineers work on the codebase, and how often do their changes block each other's releases?
2. If one part of the system suddenly needed ten times more capacity than the rest, could you scale that part alone?
3. The last time something broke in production, how long did it take to find the cause? Would having more separate services have made that faster or slower?

Keep your answers somewhere. The capstone at the end of this module asks you to make the same decision about a real system, and these three answers are most of the evidence you will need.

Start with Three Levels of Microservices Knowledge. It shows the three levels this topic works at, so you know which one you are working at.