Glossary

What is Microservices?

An architecture where an application is built as many small, independent services that communicate over a network, instead of one large program.

In plain words

A traditional application is built as one large program, often called a monolith. In a microservices design, the same application is split into many small services, each doing one job such as payments, search or notifications. Each can be built, released and scaled on its own, and they talk to each other through APIs.

What it offers

Different teams can work and release independently
A busy part can be scaled without scaling everything
A fault in one service need not stop the whole product
Different parts can use different technology where it helps

What it costs

Splitting a system adds real complexity: many things to deploy and monitor, network calls that can fail, data spread across services and harder testing. Small teams often spend more time on this machinery than on the product. Many successful products begin as a well-organised single application and split out services only when a clear need appears.

Common mistakes

Choosing microservices for a small product and team
Splitting in the wrong places, so every change touches many services
No central monitoring, so problems are hard to trace
Services that share one database, which keeps the coupling you hoped to remove

Questions to ask a company that offers this

Why does this project need microservices rather than a single, well-structured application?
How will you deploy, monitor and trace problems across services?
How many people are needed to run it day to day?
What will the hosting and tooling cost each month?
Could we start simpler and split it later?

A good company will answer these plainly and in writing. Vague or evasive answers are worth noting.

Related terms

Find companies

Explanation last read through on 13 October 2026. It is general guidance in plain language, not advice for your particular project. Tell us if something is wrong or unclear.