Microservices Architecture
Microservices is an architectural style where an application is built as a collection of many small, independent services — each one responsible for a single piece of behaviour, and each talking to the others over clean, well-defined interfaces (usually APIs). @@F{1}@@
Instead of one large application doing everything, a microservices system is a fleet of small, specialised services that work together.
What makes a service a "microservice"
- One job, clearly scoped — each service owns a single responsibility (e.g. orders, payments, users).
- Loosely coupled — services don't reach into each other's internals; they communicate only through their APIs.
- Self-contained — each service has its own code, its own database, and often its own technology stack.
- Deployable independently — you can update and ship one service without redeploying the whole system.
┌──→ Orders service ─────── its own database
User ──→ │──→ Payments service ──── its own database
└──→ Users service ─────── its own database
Because each service owns its data, there's no shared database that services fight over — another reason they stay independent.
Why teams choose microservices
- Independent deployment — you can change and release only the service that changed, instead of redeploying the entire application.
- Isolation and testability — each service can be tested on its own, without the risk of accidentally breaking unrelated parts of the system.
- Technology flexibility — each team can pick the right language or database for its specific job, rather than being locked into one stack.
- Independent scaling — the busy service can be scaled up individually, while quiet ones stay small.
The costs nobody mentions first
Microservices trade one kind of complexity for another:
- Operational overhead — many running services and many moving parts to deploy, monitor, and keep running.
- Network reality — services call each other over a network, which adds latency and can fail in ways a single process never does.
- Data consistency — because each service has its own database, keeping data in sync across services is harder than in one database with one set of transactions.
- Coordination — teams must agree on APIs and ownership, or the system can drift into chaos.
When microservices make sense
Microservices pay off when the application has enough size, team, and traffic that independent scaling and independent deployment genuinely matter. For a small app, they add overhead without benefit.