0% completed
What Microservices Actually Are
On This Page
- The Definition
- What Microservices Are Not
- The Trade
- How to Explain It
- TL;DR
1. The Definition
Microservices are a way of building an application as a set of small services. Each service runs in its own process, meaning its own running program with its own memory. Each one is independently deployable, so a team can release a change to it without coordinating with any other team. Each owns its own data, and the services communicate over a network, usually through HTTP APIs or messages.
Here is what that looks like in practice. An e-commerce platform built as microservices might have an order service, a payment service, an inventory service, and a notification service. Each one has its own codebase, its own database, and its own release schedule.
When a customer places an order, the order service calls the payment service over the network. It then publishes an event, which is a small message announcing that something happened, and the inventory and notification services react to it.
Every word in that definition matters, so take the four properties one at a time.
- Own process. Each service runs separately, as its own program. A crash in the payment service cannot take the order service down with it.
- Independently deployable. The payment team can release five times today without asking the order team. Most of the benefits come from this one property.
- Owns its own data. The payment service's database belongs to it alone. No other service reads or writes those tables directly, and they must go through the payment service's API instead. This rule can feel too strict, but the whole architecture depends on it. A later lesson on database per service is devoted to it.
- Communicates over a network. This is not a benefit. It is the cost. A function call inside one process takes nanoseconds and cannot fail on its own. A network call takes milliseconds and can fail, hang, or succeed without you ever learning about it.
2. What Microservices Are Not
Most of the confusion comes from the edges of this definition. A wrong idea here leads to wrong decisions everywhere else, so it is worth being precise about what the word does not mean.
Not "small code." Micro refers to the scope of responsibility, not the line count. A service that owns all of payments can be a large codebase and still be a well shaped microservice. Splitting a 200-line service into four 50-line services does not make the system more micro. It only makes more network calls.
Not containers or Kubernetes. Docker and Kubernetes are packaging and operations technology. Docker wraps your code so it runs the same way everywhere. Kubernetes runs and manages those wrapped programs across many machines.
You can run a monolith in a container, and many companies do exactly that. You could also run microservices on bare metal, meaning servers with no container layer at all. The architecture is about boundaries and ownership, not about how the code gets deployed.
Not a performance upgrade. Replacing an in-process function call with a network call makes each individual operation slower, not faster. Microservices can improve scalability, because you can add capacity to just the busiest service. But every request that crosses a service boundary adds latency, and anyone who says microservices are faster has not counted the time spent on network calls.
Not the only alternative to a mess. A disorganized monolith and microservices are not your only two options. There is a middle point called the modular monolith, which is one deployment unit with strict boundaries inside it. It is covered in the next lesson, and it is the option most teams should consider first.
3. The Trade
Here is the whole architecture in one sentence. Microservices trade one kind of complexity for another. You remove coordination complexity, which is everyone releasing one big thing together. You accept distribution complexity, which is many things talking over an unreliable network.
The distribution complexity is concrete:
- Calls between services can fail independently, so you need timeouts, retries, and fallback behavior everywhere.
- Data is split across databases, so a single ACID transaction, meaning one all-or-nothing database operation, can no longer cover an order and its payment together.
- Debugging one request now means following it across five services and five sets of logs.
- Every service needs its own deployment pipeline, its own monitoring, and its own on-call plan.
None of these problems exist in a monolith. All of them are solvable, and most of this course is about solving them. But each solution adds more code and infrastructure that has to be built, understood, and operated. That is why the decision matters more than any single pattern, because that extra work is only worth its cost under specific conditions.
4. How to Explain It
You will be asked to explain this more often than you expect, by new teammates, by managers, and in design discussions. A good explanation is short and includes the cost.
The 30-second answer: "An architecture where the application is split into independently deployable services, each owning its own data and communicating over the network. The main benefit is autonomy: teams can develop, deploy, and scale their services independently. The main cost is that in-process calls become network calls, so you inherit distributed systems problems: partial failures, data consistency across services, and a lot more operational overhead. It is a trade of coordination complexity for distribution complexity."
Questions that usually follow:
- "How is this different from SOA?" SOA, or service-oriented architecture, is the older generation of the same idea, from the 2000s, with a different scale and emphasis. It relied on heavyweight middleware, especially enterprise service buses, which were central systems that routed and transformed every message between applications. It also used shared contracts across a whole company. Microservices favor small independent teams, lightweight protocols like HTTP and message queues, and above all independent deployment. The classic phrase for the difference is "smart endpoints, dumb pipes", which means keeping the logic in the services and the messaging layer simple.
- "How small should a service be?" Resist giving a number. The accurate answer is that a service should be as large as one team can own and release independently, and no smaller than a boundary that can operate on its own data. A later lesson on service size treats this fully.
💡 A common mistake: describing microservices only as a list of benefits. The cost side is the part that shows whether you understand the trade, so name it without being asked.
5. TL;DR
| Definition | Independently deployable services, own process, own data, network communication. |
| The real benefit | Autonomy: each team develops, deploys, and scales on its own. |
| The real cost | Network calls fail; cross-service transactions disappear; ops overhead multiplies. |
| Not | Small code, containers, a performance upgrade, or the only alternative to a mess. |
| One-liner to keep | Coordination complexity traded for distribution complexity. |
Flashcards Review
What are microservices?
Reading Progress
0%
On This Page
- The Definition
- What Microservices Are Not
- The Trade
- How to Explain It
- TL;DR