Microservices is an architectural approach where an application is structured as a collection of loosely coupled, independently deployable services. Each service handles a specific business function (user authentication, payment processing, notifications) and communicates with other services through APIs.
The alternative is a monolithic architecture, where the entire application is a single deployable unit.
You’ll hear this when…
“We’re moving to microservices” is one of the most common architectural decisions in growing engineering organisations. The appeal is independence: teams can develop, test, and deploy their service without coordinating with every other team. If the payments service needs an update, it can be deployed without touching the user service.
Microservices are closely associated with containerisation (each service runs in its own container) and orchestration tools like Kubernetes (which manages the containers at scale).
The trade-offs
Microservices solve the coordination problems of large monoliths but introduce their own complexity. Network communication between services adds latency. Debugging a request that passes through six services is harder than debugging one that stays in a single codebase. Operational overhead increases — each service needs its own monitoring, logging, and deployment pipeline.
The common wisdom: start with a monolith, extract microservices when the pain of a monolith exceeds the complexity of distributed systems. Many successful companies (Shopify, Stack Overflow) run large monolithic applications and do just fine.
Source: Martin Fowler — Microservices