What Microservices Actually Solve

3. Fault isolation. A memory leak in the recommendation code takes down recommendations, not checkout. In a monolith, all features share one process, so any feature's crash is everyone's crash.

Here is the difficult part: the isolation is no better than your failure handling. A synchronous call is one where the caller stops and waits for the answer. If checkout calls recommendations synchronously and waits forever for an answer, the processes are separate but they still fail together. A large part of this course covers making the isolation real.

4. Independent technology and data choices. The search service can use Elasticsearch, and the analytics service can use a column store. A column store is a database that keeps data by columns instead of rows, which makes analytics queries fast. No committee has to approve either choice. This benefit is genuine, and it is also the one people value too highly.

Polyglot sprawl means running many different languages and databases across services. It has real costs: more systems to operate and more skills to hire for. Mature organizations constrain it deliberately with a short list of approved stacks.

3. What Is Not on the List

Read the list again and notice what is absent.

Raw performance is not on it. Every call that crosses a service boundary changes from a nanosecond function call into a millisecond network round trip. Add serialization on both ends, which is the work of converting data into bytes for the network and back again. A request that touches five services pays that cost five times. Microservices systems are typically slower per request than the equivalent monolith.

What they can be is more scalable, and that is a different claim about a different thing. Latency is how long one request takes. Throughput is how much load the system can handle. Microservices can raise throughput for a specific busy component, but they do not make an individual request faster.

Code quality is not on it. Boundaries do force interfaces, but you can have exactly the same discipline inside a monolith with modules, as covered in What Monoliths Do Well. Distributing bad code across a network produces distributed bad code, now with partial failures. A partial failure is when some pieces of a request succeed and others fail.

Scale by itself is not on it. "We will have a lot of users" is not a reason. Monoliths behind load balancers serve enormous traffic all over the internet. The real reason appears when parts of the system need different things: different scaling, different release cadence, different reliability budgets, different teams. Release cadence is how often each part ships, and a reliability budget is how much downtime each part can tolerate.

4. How to Explain It

You will be asked why a system is split into services, sometimes about someone else's design and sometimes about your own. The answer that works starts with the organizational benefit and states the performance cost without being asked.

The 30-second answer: "The core benefit is organizational: independent deployment. Teams ship without coordinating releases, which is what unblocks a large engineering org. After that comes independent scaling, when one component's load is much larger than the rest. Next come fault isolation, so one component's failure does not become everyone's outage, and freedom to choose the right storage or stack per service. What is deliberately not on my list is raw performance. Cross-service calls are slower than in-process calls, so microservices usually add latency and give you throughput and autonomy."

Questions that usually follow:

1. "You said independent deployment is the main benefit. When does that benefit fail to appear?" When services are so entangled that every feature touches three of them, so releases still require coordination. That system is a distributed monolith, an anti-pattern with its own lesson later in this course.
2. "How many engineers before microservices make sense?" There is no single correct number, but the useful guidelines all count teams rather than users. Below roughly 20 to 50 engineers, the coordination problem that microservices solve barely exists. Present any number you give as a guideline about team count, not a fixed threshold about traffic.

💡 If you remember one line from this lesson, start with independent deployment. Scalability is the answer almost everyone gives first, and it is the least accurate one.

A common mistake: answering "why microservices?" with "because they scale better" and nothing else. Those five words get three separate things wrong. Scale alone is not the reason. Per-request performance gets worse, not better. And the real main benefit, deployment autonomy, went unmentioned.

5. TL;DR