How it works
Each service, such as accounts, payments, search or notifications, has its own codebase, its own database and its own deployments, and talks to the others through APIs (REST, gRPC) or message queues. Teams can pick the language that suits each service, release on their own schedule and scale only the parts under load, usually with containers on Kubernetes or on serverless platforms.
The price is complexity. Network calls fail and add delay, data spread across many databases is hard to keep consistent, and following one request through many services needs proper monitoring and tracing. Microservices mostly solve an organisational problem, many teams working on one product, which is why they tend to pay off at large scale rather than at the start.
Microservices pros and cons
Pros
- Teams release and scale their services independently
- A failure can be contained to one service
- Each service can use the technology that suits it
- Smaller codebases that are easier to understand one at a time
Cons
- Much more operational work: deployment, monitoring and tracing
- Network calls add delay and new ways to fail
- Keeping data consistent across services is hard
- Expensive in infrastructure and people for small teams
When to use Microservices
Pick it when
- Large organisations with many teams working on one product
- Parts of a system with very different scaling or reliability needs
Skip it when
- A new product or a small team (start with a monolith)
- You lack the monitoring and DevOps skills to run many services
Microservices vs the alternatives
Related terms
More in Rendering and architecture
Architecture