0% completed
What Microservices Actually Solve
On This Page
- The Problem Is Organizational, Not Technical
- The Four Genuine Benefits
- What Is Not on the List
- In the Interview
- TL;DR
1. The Problem Is Organizational, Not Technical
Here is the single most useful sentence in this module: microservices solve organizational problems, not performance problems. Nearly every strong interview answer about the architecture rests on that sentence. Nearly every weak one contradicts it.
Consider where the architecture came from. In its early years of rapid growth, Amazon had a growing monolith and hundreds of engineers. The technical system worked. The human system did not.
Every release required coordinating dozens of teams onto one deploy train. A deploy train is a shared release schedule: everyone's changes ship together, or nobody's do. A delay in one team's feature delayed everyone. Merge conflicts, freeze windows (periods when no one is allowed to deploy), and release meetings consumed more engineering time than engineering did.
Amazon's fix was organizational. Small teams would each own a service they could deploy on their own, without asking anyone. Amazon later described these as "two-pizza teams," meaning a team small enough that two pizzas can feed it. The architecture change was really a team-structure change. Netflix made the same move a few years later, under the same pressures.
There is a name for this idea: Conway's law. It says that organizations produce designs that copy their communication structures. In plain terms, your architecture ends up looking like your org chart. Microservices apply the law on purpose, in reverse. Draw the system boundaries where you want team boundaries, so each team can move without meetings.
2. The Four Genuine Benefits
1. Independent deployment. The payment team ships on Tuesday. The search team ships four times the same day. Neither knows about the other. Release trains, coordination meetings, and company-wide freeze windows disappear.
This is the headline benefit, and one detail is worth stating precisely: the value scales with the number of teams. Ten services owned by one team of six people gets almost none of it. The six people still coordinate in standup.
2. Independent scaling. When one part of the workload dwarfs the rest, you can scale that part alone. Suppose image processing needs 40 servers of capacity while everything else needs 4. A monolith forces you to run 40 copies of everything, because the whole app is one deployment unit. As a separate service, image processing scales by itself, and the rest of the system stays small.
The benefit is real money. Note the shape of the condition, though: the load profiles must actually be different. If every part of the system carries the same load, this benefit gives you nothing.
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 tricky part: the isolation is only as good as 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 and the fates are still shared. 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 database that stores data by columns instead of rows, which makes analytics queries fast). No committee has to approve either choice. This benefit is genuine, but it is the one candidates overweight most often.
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 tax 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 buy throughput for a specific hot 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 (situations where 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 (how often each part ships), different reliability budgets (how much downtime each part can tolerate), different teams.
4. In the Interview
The direct forms are "What are the benefits of microservices?" and its sharper sibling, "Why would you choose microservices here?" pointed at your own design.
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 cost latency and buy throughput and autonomy."
Likely follow-ups:
- "You said independent deployment is the main benefit. When does that benefit not materialize?" 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.
- "How many engineers before microservices make sense?" There is no magic number, but the industry heuristics cluster around needing multiple teams first. Below roughly 20 to 50 engineers, the coordination problem that microservices solve barely exists. Frame any number you give as a heuristic about team count, not a threshold about traffic.
💡 If you remember one line for this question, lead with independent deployment. Interviewers hear "scalability" from every candidate. Naming the organizational benefit first is what marks you as senior.
A red flag that fails candidates: answering "why microservices?" with "because they scale better" and nothing else. It compresses everything wrong into five words. Scale alone is not the reason. Per-request performance gets worse, not better. And the actual headline benefit, deployment autonomy, went unmentioned.
5. TL;DR
| The sentence | Microservices solve organizational problems, not performance problems. |
| Benefit 1 | Independent deployment; value scales with number of teams. |
| Benefit 2 | Independent scaling, when load profiles genuinely differ. |
| Benefit 3 | Fault isolation, if failure handling makes it real. |
| Benefit 4 | Per-service tech and data choices, used sparingly. |
| Not benefits | Per-request performance, code quality, "scale" as a slogan. |
Flashcards Review
What single sentence should anchor every answer about what microservices solve?
On This Page
- The Problem Is Organizational, Not Technical
- The Four Genuine Benefits
- What Is Not on the List
- In the Interview
- TL;DR