A microservice is a small, independently deployable service that handles one business capability, such as orders, payments or user accounts. In a microservices architecture, an application is built from many of these services, each with its own code base and usually its own database, communicating with each other through APIs or messages. The opposite is a monolith: one application that contains all functionality and is deployed as a whole.
How do microservices work?
- One responsibility per service: each service owns one part of the domain and its data.
- Communication over the network: synchronous calls via REST or gRPC, or asynchronous events via a message broker such as Kafka or RabbitMQ.
- Independent deployment: a service can be changed, tested and released without redeploying the rest.
- Independent scaling: only the services under heavy load get extra instances.
- Containers and orchestration: services typically run in Docker containers, managed by Kubernetes or a similar platform.
Microservices vs. monolith
A monolith is simpler to build, test, deploy and debug, and for most new applications it is the right starting point. Microservices help when an application and its organisation grow: several teams that need to release independently, parts with very different load or technology needs, or a system where one failing component must not bring down everything else. A popular middle ground is the modular monolith: one deployable application with strict internal boundaries, which can later be split into services where that actually pays off.
Advantages and drawbacks
Advantages: independent releases, targeted scaling, fault isolation, and freedom to choose the best technology per service.
Drawbacks: a distributed system is much harder to operate. Network calls fail, data is spread across databases, transactions across services need patterns such as sagas, and you need solid monitoring, logging, tracing and CI/CD to keep track of everything. Many teams underestimate this operational overhead.
When should you choose microservices?
Choose microservices for a clear reason, not as a default: multiple teams working on one product, parts with very different scaling needs, or a legacy system that is being replaced piece by piece. Otherwise, start with a well-structured monolith. Need help with this choice? See our IT architecture consultancy and API development.
Frequently Asked Questions about Microservices
What is the difference between a microservice and an API?
A microservice is a standalone piece of software; an API is the interface through which it is used. Each microservice exposes an API, but an API can just as well belong to a monolith.
How small should a microservice be?
There is no fixed size. A useful rule is that a service covers one business capability that one team can own completely. Services that are too small create a lot of network traffic and coordination.
Do microservices always need Kubernetes?
No. Kubernetes is common for larger setups, but a handful of services can run perfectly well on managed container services or plain virtual machines.
Can a monolith be converted to microservices?
Yes, usually gradually: new functionality and clearly separable parts are moved into services one at a time while the monolith keeps running (the strangler fig pattern).