What Microservices Actually Are

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 is independently deployable: a team can ship 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. Then it publishes an event (a small message announcing that something happened) that the inventory and notification services react to.

Every word in the definition carries weight. Take the four properties one at a time:

1. Own process. Each service runs separately, as its own program. A crash in the payment service cannot take the order service's process down with it.
2. Independently deployable. The payment team can ship five releases today without asking the order team. This is the property most of the benefits flow from.
3. Owns its own data. The payment service's database belongs to it alone. No other service reads or writes those tables directly. They must go through the payment service's API. This rule feels bureaucratic, but it quietly holds up the whole architecture. A later lesson on database per service is devoted to it.
4. Communicates over a network. This is not a benefit. It is the price. 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

Interviewers like to probe the edges of this definition. This is because misconceptions here predict mistakes everywhere else.

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 just 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. 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 bytes get 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 hot service (the one taking the most traffic). But every single request that crosses a service boundary pays a latency tax. Candidates who say "microservices are faster" reveal they have not thought about where the time goes.

Not the only alternative to a mess. A disorganized monolith and microservices are not your only two options. There is a middle point, the modular monolith: one deployment unit with strict boundaries inside it. It is covered in the next lesson, and interviewers increasingly expect you to know it.

3. The Cost Ledger

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 (one all-or-nothing database operation) can no longer cover an order and its payment together.
• Debugging a request now means following it across five services and five sets of logs.
• Every service needs its own deployment pipeline, monitoring, and on-call story.

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 machinery that must be built, understood, and operated. This is why the decision lesson matters more than any pattern lesson: the machinery only pays for itself under specific conditions.

4. In the Interview

The question is usually direct: "What are microservices?" or "How would you explain microservices to a new engineer?"

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."

Likely follow-ups:

1. "How is this different from SOA?" SOA (service-oriented architecture) is the older generation of the same idea, from the 2000s, with a different scale and emphasis. It leaned toward heavyweight middleware, especially enterprise service buses (central systems that routed and transformed every message between applications), and toward shared contracts across a whole company. Microservices favor small independent teams, lightweight protocols like HTTP and message queues, and above all independent deployment. If you mention the classic phrase "smart endpoints, dumb pipes" (keep the logic in the services, keep the messaging layer simple), you have said enough.
2. "How small should a service be?" Resist giving a number. The honest 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 red flag that fails candidates: describing microservices purely as a list of benefits. Interviewers are explicitly checking whether you know it is a trade, and the cost side of your answer is the part being scored.

5. TL;DR