Module Introduction

1. What This Module Covers

There are two ways to build a large application: as one program (a monolith), or as many small, independent services that talk to each other over a network (microservices).

Most software engineers prepare for microservices interviews by memorizing patterns: circuit breakers, sagas, API gateways. Then the interviewer asks a question that comes before all of them. "Why microservices at all?" The memorized material does not help.

This module is about that decision. When does splitting a system into services make sense? When does it not? And how do you defend your answer out loud?

Interviewers care about this question because it separates two kinds of candidates: those who have read about microservices, and those who can reason about them. Saying "microservices, because they scale better" is one of the fastest ways to fail a senior interview. By the end of this module, you will know exactly why.

The industry context matters too. For about a decade, microservices were the default choice. That has changed. In a survey by the Cloud Native Computing Foundation (CNCF), the group behind Kubernetes, 42% of organizations that adopted microservices said they were merging some services back into larger ones. Amazon's own Prime Video team published a case study where merging a distributed pipeline into a single process cut its infrastructure cost by 90%. Interviewers read the same articles you do.

So the expected answer is no longer "always split." The strong answer sounds like this: "Here is what splitting buys us. Here is what it costs. And here is the evidence I would need before doing it."

💡 In a senior interview, "I would not use microservices here, and here is why" can be a stronger answer than any pattern you name. The decision is the signal, not the vocabulary.

2. The Lessons

Each lesson answers one question you will face in a real interview.

3. Two Terms Used Throughout

1. Deployment unit. The thing you build, test, and release as one piece. A monolith is one deployment unit. A microservices system has many, and each one ships on its own. Most trade-offs in this course come back to a single number. How many deployment units do you have?
2. Independently deployable. A service is independently deployable when your team can ship a change to it without waiting for any other team. This is the property that makes microservices worth their cost. Here is the test. If every release still needs three teams to deploy together, you are not getting the benefits, no matter how many services you have.

4. Before You Start

Answer these three questions for a system you know well. Rough answers are fine. The module will sharpen them.

1. How many engineers work on the codebase? How often do their changes block each other's releases?
2. If one part of the system needs 10 times more capacity than the rest, can you scale just that part?
3. Think about your last production incident. How long did it take to find the cause? Would more moving parts have made that faster or slower?

Start with How Microservices Show Up in Interviews. It covers the three question shapes that everything else in this course prepares you for.