What is Microservices?
Definition
Microservices is an architectural style in which an application is built as a set of small services, each responsible for one business capability, owning its own data and deployable independently. Services communicate over the network through APIs or messages. The style enables independent scaling and team autonomy, at the price of distributed-systems complexity: network failures, data consistency and much heavier operations.
Also known as: Microservice architecture, Microservice, Micro-services
Compared with a monolith
A traditional monolith is built from one codebase and released as one unit. A microservices system splits the same application along business capabilities. In an online shop, catalogue, cart, payments and shipping become separate services, each with its own codebase, its own database and its own release cadence. Changing the payment service does not mean redeploying the catalogue.
Services talk to each other in two ways: synchronously, through a REST API or gRPC call, or asynchronously, through a message queue or event stream. Publishing an "order placed" event and letting interested services react at their own pace keeps them less tightly coupled than a chain of direct calls.
What you actually gain
- Independent deployment: teams ship without waiting for each other, replacing large risky releases with small, frequent ones.
- Targeted scaling: during a sale you scale the cart service, not the whole application.
- Fault isolation: designed well, a crash in the recommendations service does not take checkout down with it.
- Team ownership: each team owns its service end to end — a decisive advantage when many teams work on one product.
What it costs
- The network is unreliable. A function call becomes a request that can be slow or fail halfway. Timeouts, retries and circuit breakers stop being optional.
- Consistency gets hard. There is no transaction spanning services. Keeping order, payment and stock in step requires patterns such as sagas and accepting eventual consistency.
- Observability is mandatory. When one request crosses five services, debugging without centralised logs, metrics and distributed tracing is close to impossible.
- Operations multiply. Every service needs its own CI/CD pipeline, container image, monitoring and security patching.
- Contracts need managing. Changes to one service's API must be versioned so they don't break its consumers.
The modular monolith alternative
A modular monolith is deployed as a single unit but organised into strictly separated modules that never reach into each other's tables and only communicate through defined interfaces.
| Modular monolith | Microservices | |
|---|---|---|
| Deployment | One unit | One per service |
| Calls between modules | In-process function calls | Network requests or messages |
| Consistency | A single database transaction is possible | Sagas, eventual consistency |
| Operational overhead | Low | High |
| Best fit | Small and mid-sized teams; domains still taking shape | Many independent teams; markedly different scaling needs |
The worst outcome is a "distributed monolith": services that run separately but share a database or must always be deployed together. You pay every cost of distribution and keep none of the benefits. Extracting a single module into its own service once a concrete need appears is usually far less risky than starting with dozens of services on day one.
Questions to ask before splitting
- Do several teams genuinely need to release independently?
- Do parts of the system have clearly different scaling profiles?
- Are the domain boundaries — which data belongs to which service — well understood?
- Are automated deployment, central logging and monitoring already in place?
If most answers are "no", the complexity microservices introduce will probably outweigh what they deliver.