Glossary · Software Architecture
What are microservices?
Short answer
Microservices are an architecture style where an application is built as a set of small, independently deployable services, each owning one business capability and its own data, and communicating over APIs or events. They let teams release and scale parts of a system separately, at the cost of more operational and distributed-systems complexity than a single application (a monolith).
What makes a service a microservice
- It owns one business capability, such as billing or search, and its own database.
- It can be deployed without redeploying anything else.
- Other services use it only through its API or the events it publishes, never by reading its tables.
Benefits
Teams can work and release independently, scale the busy parts only, and use different technologies where it really helps. A failure in one service can be contained rather than taking the whole product down.
Costs
Every network call can fail or be slow; data is spread across services, so reports and transactions get harder; you need service discovery, monitoring, tracing and automated deployment from day one. Many teams adopt microservices too early and spend their time on infrastructure instead of the product.
A practical path
Start with a well-structured modular monolith, with clear module boundaries inside one codebase, and extract a service only when a module has a clear reason: a different scaling profile, release cadence or team. When replacing a legacy system, the strangler fig pattern lets you do this gradually.
Frequently asked questions
Are microservices better than a monolith?
Not by default. For small and medium teams a modular monolith is usually faster to build and run. Microservices pay off when many teams need to release independently or parts of the system have very different scaling needs.
