Microservices

What it means

Microservices are a software architecture in which an application is made up of many small independent services. Each handles one area, such as orders, payments, inventory or invoicing, owns its data and communicates with the others through an API, most often a REST API or messaging.

The opposite is a monolith, a single large application in which all parts are bound together in one codebase and deployed at once. A monolith is simpler at first but harder to change and scale as it grows. Microservices let different teams develop and deploy their parts independently.

Microservices usually run in containers provided by containerisation and are managed by orchestrators such as Kubernetes. Each service can therefore be scaled separately, for example adding capacity only to the payment service during a sale.

How it works in practice

The architecture pays off for large, fast-growing applications with several teams, where independence and frequent change matter. Each service is deployed automatically through CI/CD and run by a team working in a DevOps culture that owns the service from development to operation.

Services should be split along business domains, not technical layers. An invoicing service should contain everything belonging to invoicing, so that when rules change, for example with e-invoicing, ten different parts do not have to be modified.

With many services, central collection of logs, metrics and request tracing across services is essential. Without it, finding an error that occurs somewhere in a chain of five services is very time-consuming. Documenting the interfaces between services is also important.

What to watch out for

Microservices significantly increase operational complexity: more deployments, networking, monitoring and ways for communication to fail. For a small team or a simple product, a well-structured monolith that can be split later, when there are real reasons, is often better.

Because each service has its own data, consistency is harder to ensure, for example that an order, a payment and a stock movement always match. For financial and accounting processes, error handling and retries must be designed carefully to avoid duplicate payments or missing documents.