A microservice is one small, self-contained program that does a single job and communicates with other services over the network. Instead of building your whole application as one large codebase, you split it into many narrow services, each owning a clear capability such as payments, search, or notifications. Each can be deployed, scaled, and even written in a different language on its own. In 2026 the pattern is mature and well understood, which also means the industry is more honest than it used to be about when it helps and when it just adds overhead.
What a microservice actually is
The word describes a size and a boundary, not a specific technology. A microservice is small enough that one team can understand and own it, and it has a boundary clear enough that it can change internally without forcing changes elsewhere.
A single service typically owns its own data, exposes an interface to the outside world, and runs as its own process. If you have to redeploy three other services every time you touch this one, it is not really independent, and you have lost most of the benefit.
How the pieces fit together
Microservices coordinate by sending messages, not by calling functions in shared memory, often through an API endpoint. There are two common styles.
| Communication style |
How it works |
Best for |
| Synchronous (HTTP/gRPC) |
One service calls another and waits for a reply |
Simple request/response flows |
| Asynchronous (message queue) |
Services publish events others react to later |
Decoupling, spikes, background work |
| API gateway |
A single entry point routes outside requests inward |
Hiding internal layout from clients |
Most real systems mix these. A web request might hit a gateway, get routed to an orders service synchronously, and that service then drops an event onto a queue for the email service to pick up whenever it is ready.
-- A request crosses a network boundary between two services
curl https://orders.internal/api/orders/42
Microservice vs monolith
| Approach |
Strength |
Trade-off |
| Monolith |
Simple to build, deploy, and debug |
Hard to scale teams; one big deploy |
| Microservices |
Independent teams and scaling |
Network, monitoring, and data complexity |
A monolith is not the wrong answer. For most small and mid-size applications it is the right one, because everything runs in a single process where calls are fast and debugging is straightforward. Microservices earn their keep when you have enough engineers that one big codebase becomes a coordination bottleneck, or when one part of the system needs to scale very differently from the rest.
When to choose microservices
- You have multiple teams stepping on each other. Independent deploys remove the queue of people waiting to ship.
- One component has very different scaling needs. Search or video processing can scale alone instead of dragging the whole app along.
- You need fault isolation. A crash in one service should not take everything down.
- You have the operational muscle. You need solid logging, tracing, and deployment automation first, not after.
If none of these apply, a well-organized monolith will serve you better and cost far less. You can always split later once the seams are obvious.
What to skip
- Premature splitting. Carving a tiny app into ten services buys complexity with no payoff. Start with a clean monolith.
- A shared database across services. If two services read and write the same tables, they are coupled and you have a distributed monolith, the worst of both worlds.
- Chatty synchronous chains. A request that hops through six services in series is slow and fragile. Prefer events where you can.
- Ignoring observability. Without distributed tracing, debugging across services is guesswork.
FAQ
How small should a microservice be?
Small enough that one team can own it and explain it in a sentence, but no smaller. There is no line count; the right size is one clear responsibility with a stable boundary.
Do microservices need separate databases?
Ideally yes. Each service owning its own data is what makes it independent. Sharing one database recreates the coupling you were trying to escape.
Are microservices faster than a monolith?
Usually not for a single request, since network calls add latency a function call does not. The win is in team velocity and independent scaling, not raw speed.
Is a microservice just a small API?
It exposes an API, but the defining trait is independence: its own deployment, data, and lifecycle. A small endpoint inside a monolith is not a microservice.
Where to go next
See what a server is in 2026, what a REST API is in 2026, and what a port is in 2026.